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
@oloturia @mike @informatica
Tutto il discorso si ricollega poi all’equilibrio tra social di comunità principalmente poggiante sull’istanza locale e oligopolio di istanze enormi dove una vale l’altra, che negli ultimi tempi si sta sbilanciando verso la seconda.
Un mondo di piccole istanze è inevitabilmente meno collegato per mere questioni di discoverability, non è interessante per i vips, e cmq la singola istanza avrebbe difficoltà a dedicargli le risorse necessarie.
@oloturia @mike @informatica
Una grande istanza può fornirgli i numeri che desiderano, ma non ha le risorse per gestire bene la cosa anche solo come moderazione, specialmente al di fuori dei propri confini.
In altre parole nel salto di scala o ci rimette molto la qualità dell’esperienza, o vi sono altri meccanismi di finanziamento che professionalizzano il servizio.
@NicholasLaney @oloturia @mike @informatica
si, un fediverso di piccole-medie istanze sarebbe molto meglio di quello presente, per i motivi che dici (moderazione) e tanti altri.
lo iato di cui dici, tra istanze piccole e istanze grossissime, però, non è che “negli ultimi tempi si sta sbilanciando verso la seconda”, è che da sempre mastodon fa accentramento su mastodon.social e le istanze più grosse qui, https://joinmastodon.org/servers, e rendendo mastodon.social il default, super spinto a livello di interfaccia, nelle app ufficiali.
Rispetto a questa situazione, la discoverability - per es. con un db distribuito con gli hashtag e i nomi utente dei profili dell’utent* che scelgono di rendersi “trovabili*” - andrebbe a vantaggio, non a detrimento della decentralizzazione: …
(1/2)
deleted by creator
@NicholasLaney @oloturia @mike @informatica
…perché annullerebbe la necessità di iscriversi a istanze grosse per poter fare un discovery più esteso.
(2/2)
@jones @oloturia @mike @informatica
C’è una serie di implicazioni su cui è importante riflettere, proprio a livello di architettura e risorse.
Una discoverability (che brutto termine troviamone un’altro) più estesa implica un maggiore carico sul database, che a sua volta implica svuotarlo più spesso, quindi avere meno “memoria” nel tempo.
Tutto si somma a formare un equilibrio in cui diverse combinazioni sono possibili ma la lunghezza della coperta è determinate dalle risorse.
@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)