No et pensis que no m'agrada veure com les etiquetes en tendència son una realitat en el codi d'appy 😃
Les aplicacions client obtenen les dades dels darrers 7 dies des d'appy per a mostrar quines etiquetes son tendència.
Mastodon no permet entrar en tendència als enllaços a tuts del fedivers.
A #appy es mostraven en les tendències però he tingut una bona idea per evitar-ho, tant l'usuari que ha publicat el tut com el seu domini ja estan desats en la base de dades abans d'obtenir les meta dades Open Graph per a generar les "preview cards". Un petit filtre verifica que el domini no hi sigui en la taula accounts abans de processar les metadades del enllaç.
![for url in urls:
url_domain = urlparse.urlparse(url).netloc
is_fediverse = await db.is_fediverse_domain(url_domain, status.get('account_id'))
if not is_fediverse:
fn @Er whe URL
| headers = {'User-Agent': 'appy - httpx'}
1215V/ 8
async with httpx.AsyncClient(timeout=3.0) as client:
response = await client.get(url, headers=headers)
# Analize HTML content
soup = BeautifulSoup(response.content, 'html.parser')
# Search OpenGraph data
for tag in soup.find_all('meta'):
if tag.get('property') and tag.get('property').startswith('og:'):
og_tags[tag.get('property')] = tag.get('content')](https://mastodont.cat/system/media_attachments/files/115/729/190/347/925/571/original/45fdd171cd3886c5.png)
Aquest és el diagram de flux a #appy quan rep una activitat Create (un tut remot). El necessito per ajudar-me a fer l'algorisme que ha d'obtenir el tut remot al qui l'activitat Create ha respòs si és que encara no hi és a la base de dades.
Les IA no van saber dir-me la solució però mentres provaba el que em deien, sense èxit, s'en va encendre la llum.
Els tuts antics es mostraven dalt de tot de la línia de temps perquè el codi d'appy els assignava una snowflake id en base a la data actual. La solució va ser fàcil, afegir un segon paràmetre a la funció que les genera, així els tuts nous li passen la data actual i els tuts antics la seva data de publicació.
Les línies de temps s'ordenen per la id del tut (una snowflake id).
#appy
Perfecte, l'algorisme d'etiquetes en tendència d'appy ja funciona raonablement bé (com Mastodon).
Des de Misskey es veuen els servidors #appy com cal, amb el seu logo oficial i la versió en execució. 😀
Fa temps que vaig llegint que Mastodon (el servidor) menja molts recursos de màquina i que hi ha altres programaris fediversals molt més lleugers. Cert, per exemple, Mastodon no el pots instal·lar en una Raspberry Pi 3B+, però sí que pots posar-li Pleroma o Akkoma.
El que em fa sentir orgullós és que el meu propi servidor que estic programant amb #fastAPI ( #Python), #appy, és encara més lleuger que Pleroma o Akkoma.
En el mateix servidor, Pleroma consumeix 2,5% de CPU, Akkoma 1,5% i appy 0%
Magnífic, tant Pleroma com Akkoma accepten l'activitat Delete user que reben d'appy i actuen en consecuència, esborren l'usuari de les seves bases de dades. 👏
O sigui, Akkoma, Mastodon i Pleroma no deixen brossa del servidor appy quan aquest els hi diu "ei, que tanco la paradeta, esborreu tot de mi."
Oh! el meu projecte #appy ja té 8 estrelles i 3 forks. 😀
Genial, ja he implementat el codi per a des federar un servidor #appy. Envia una activitat Delete a tots els servidors federats per a que esborrin de la seva base de dades tots els usuaris locals i deixin així d'interaccionar amb ells.
És una manera neta de deixar el fedivers, sense que hi quedi brossa del servidor aturat per sempre.
![Delete activity for user perfil successfully sent to https://expressional.social/inbox: <Response [202 Accepted]>
2025-10-21 13:00:05.206 | INFO | __main__:send_delete:36 —
Delete activity for user perfil successfully sent to https://mastodon.cloud/inbox: <Response [202 Accepted]>
2025-10-21 13:00:05.305 | INFO | __main__:send_delete:36 —
Delete activity for user perfil successfully sent to https://infosec.exchange/inbox: <Response [202 Accepted]>
2025-10-21 13:00:05.519 | INFO | __main__:send_delete:36 —
Delete activity for user perfil successfully sent to https://techhub.social/inbox: <Response [202 Accepted]>
2025-10-21 13:00:05.645 | INFO | __main__:send_delete:36 —
Delete activity for user perfil successfully sent to https://mstdn.social/inbox: <Response [202 Accepted]>
2025-10-21 13:00:05.697 | INFO | __main__:send_delete:36 —
Delete activity for user perfil successfully sent to https://tldr.nettime.org/inbox: <Response [202 Accepted]>
2025-10-21 13:00:05.699 | INFO | services.postgres:disconnect:49 — Database connection pool has been closed.
2025-10-21 13:00:05.699 | INFO | __main__:main:67 — Database connection closed.
2025-10-21 13:00:05.699 | INFO | __main__:main:68 -
Done §. Now you can stop your appy server.
(appy) dev@spla:~/appy$ lI](https://mastodont.cat/system/media_attachments/files/115/411/824/173/907/557/original/ccb4c663c19cecd8.png)
El desenvolupament del servidor #ActivityPub #appy ( :appy: ) no s'atura. Fa quatre dies vaig alliberar la versió v0.3.0:
https://codeberg.org/spla/appy/releases/tag/v0.3.0
He descobert que no cal afegir la clau "signature" dins de l'objecte json de l'activitat Create que s'envia als servidors federats quan appy publica un tut. És quelcom redundant.
Els servidors Akkoma, Mastodon, Misskey i Pleroma sí que miren i validen la HTTP Signature que el codi d'appy envia sempre dins dels headers però no miren que hi hagi la clau "signature" dins del json de la pròpia activitat rebuda.
Millor, menys codi.
![# Crear el camp "signature" dins l'activitat
activity['signature'] = {
'type': 'RsaSignature2017',
‘creator': activity['actor'] + '#main-key',
'created': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ'), # Format ISO 8601 amb Z
'signatureValue': signature_bé64
}](https://mastodont.cat/system/media_attachments/files/115/111/419/830/233/157/original/1e11ff5db2bef3a6.png)
Perfecte! els emojis que envia el servidor appy ja arriben perfectament als servidors Akkoma, Mastodon, Misskey i Pleroma 😎
El model Pydantic era massa estricte, no permetia afegir 'Emoji': 'toot:Emoji' en el seu context.
Ah, i els emojis que rep appy des del fedivers els desa en local.
4 media
- 3 servidors #appy necessiten 192+173+117 = 482 megues de RAM
- 1 servidor #Mastodon 322+300+290+290 = 1.202 megues de RAM
- 1 servidor #Pleroma (veure imatge) 491 megues de RAM
- 1 servidor #Akkoma (veure imatge) 395,3 de RAM
Tots els servidors tenen un sol usuari actiu.
#appy és la millor opció, clarament (#Python #fastAPI) 😀
4 media
- 3 servidors #appy necessiten 192+173+117 = 482 megues de RAM
- 1 servidor #Mastodon 322+300+290+290 = 1.202 megues de RAM
- 1 servidor #Pleroma (veure imatge) 491 megues de RAM
- 1 servidor #Akkoma (veure imatge) 395,3 de RAM
Tots els servidors tenen un sol usuari actiu.
#appy és la millor opció, clarament (#Python #fastAPI) 😀
4 media
A IceCubes ja li comença a agradar el codi d'appy. Era l'única aplicació client de Mastodon que no mostrava els tuts de les línies de temps Inici i Federada si habia tuts amb respostes però he trobat dues incidències en el codi que he endreçat.
#appy