Il fediverso non è ancora pronto per le persone con molto seguito?
Il noto youtuber Alec di Technology Connections, migrato su mastodon da twitter, si sfoga affermando che la sua presenza nel fediverso è problematica per via della moderazione infra-istanza, che reputa inefficiente per un account che ha molto seguito come il suo (e si parla di “solo” 35mila seguaci sugli oltre 2 milioni di iscritti al suo canale YT)
Link al thread in questione: https://mas.to/@TechConnectify/111428308227305812
@jones @oloturia @mike @informatica
E poi, detto fuori dai denti: se il risultato finale è avere una manciata di istanze che hanno una copia di tutto il fediverso in database, si ottiene tutti gli svantaggi di un social centralizzato e tutta l’inefficienza (rindondanza) di uno decentralizzato.
In quest’ottica è poco desiderabile che istanze piccole abbiano una conoscenza ampia del fediverso, sarebbe un consumo di risorse sostanzialmente inutile.
@jones @oloturia @mike @informatica
Probabilmente esitono meccanismi più efficienti per una struttura decentralizzata, ma non è il caso di mastodon. E che io sappia neanche quello delle alternative più sviluppate.
@NicholasLaney @oloturia @mike @informatica
Non si tratterebbe di poche istanze con un database condiviso di tutto il fediverso, ma di un database distribuito e in costante sincronizzazione tra i nodi, ovvero tra tutte le istanze, in pratica per quanto riguarda il peso sarebbe una sola tabella in più nel db di mastodon, che è postgresql, con i soli hashtag di profilo e l’indirizzo dellə utent* che scelgono (opt-in, come già avviene) di essere trovabili. Ci vorrebbe un protocollo per la sincronizzazione, ma forse basterebbe riadattare quello che usavano e ancora usano molti keyserver openpgp che sincano tra loro un gran numero di chiavi pubbliche. (1/2)
@NicholasLaney @oloturia @mike @informatica
Il peso non sarebbe eccessivo, un paio di settimane fa ho fatto prova sul mio modesto pc con una tabella in postgresql strutturata come potrebbe esserlo e popolata da dati random, e ogni query prendeva circa 0.3 secondi. (2/2)
deleted by creator
@NicholasLaney @oloturia @mike @informatica
(Ah, aveva tanti record quanti sono gli utenti mastodon ora, diviso due, come stima super spannometrica ma sicuramente al rialzo del numero di utenti che scelgono di rendersi trovabili qui, e come spazio su disco occupava sui 15 gb).
@NicholasLaney @oloturia @mike @informatica
Ma, evidentemente, non c’è alcuna volontà “politica” da parte del team di sviluppo di mastodon per implementare una cosa così, proprio perché sarebbe decentralizzante, e il team di sviluppo ha già abbondantemente dimostrato che punta alla centralizzazione su pochi grossi server e in particolare su mastodon.social, di gran lunga il più grosso.
@NicholasLaney @oloturia @mike @informatica
Occupy team di sviluppo di mastodon! :)
In realtà sarebbe da scrivere un nostro server activitypub, oppure forkare mastodon, ma seriamente, con un team grossetto.
deleted by creator
@jones @oloturia @mike @informatica
C’è solo un problema: tutto ciò che hai fatto è stato spostare il carico dal db alla banda.
Che è pure peggio, soprattutto in termini ambientali.
Non che debba essere quello l’unico criterio, ma inventarci metodi sempre più complessi per consumare maggiori risorse mi sembra il contrario di ciò che è necessario.
@NicholasLaney @oloturia @mike @informatica
Ma in realtà anche dal punto di vista della banda ne succhierebbe ben poca: un protocollo come quello per la sincronizzazione delle chiavi pubbliche openpgp sui keyserver non succhia tanta banda, e se si vedesse che invece nel nostro caso, via via che lə utent* aumentassero, lo farebbe, si potrebbe modulare una finestra temporale per l’update degli hashtag e del “nome visualizzato” dei profili, tipo: puoi modificarli solo 10 volte al giorno, aggiustandola via via alla bisogna.