Il fediverso non è ancora pronto per le persone con molto seguito?

@informatica

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@puntarella.party
      link
      fedilink
      arrow-up
      1
      ·
      10 months ago

      @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)

          • Jones@puntarella.party
            link
            fedilink
            arrow-up
            1
            ·
            10 months ago

            @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.

              • Nicholas Laney :copyleft2:@nebbia.fail
                link
                fedilink
                arrow-up
                1
                ·
                10 months ago

                @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.

                • Jones@puntarella.party
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  10 months ago

                  @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.

                  • Jones@puntarella.party
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    10 months ago

                    @NicholasLaney @oloturia @mike @informatica
                    Aggiungendo alla tabella con indirizzo, “nome visualizzato”, hasthtag di profilo e timestamp dell’ultimo update, un’altra tabella, molto più leggera, con tutte le istanze, ugualmente sincronizzata tra tutte le istanze, ma ovviamente molto più lentamente (aprono e chiudono molto più lentamente di quanto possano essere modificati i profili), il protocollo non richiederebbe che l’istanza di gigi che ha appena modificato il suo profilo comunicasse a tutte le altre la modifica: potrebbe comunicarla solo a una, dicendo “sono l’istanza x e ho comunicato solo a te la modifica del profilo di gigi”; la seconda, y, potrebbe allora comunicare la modifica a una terza tra quelle ancora non coperte, dicendo “gigi su x ha modificato il suo profilo così, si sa su x e y”, ecc.