[-] [email protected] 2 points 10 months ago* (last edited 10 months ago)

@NicholasLaney @oloturia @mike @informatica
I server scambierebbero solo indirizzo, "nome visualizzato", i primi 5 hashtags di profilo e un timestamp, non l'immagine né nient'altro, e lo farebbero solo quando questi dati fossero modificati da un utente (e si potrebbe limitare la possibilità di farlo a 5 volte al giorno). Così per esempio potresti cercare "greta thunberg" e trovarla sul server dove sta anche se nessun* dal tuo server l'avesse mai seguita o ci avesse mai interagito prima, e il suo profilo completo, con immagine e tutto, sarebbe scaricato dalla tua istanza solo qualora cliccassi sul risultato nella lista (allora potresti verificare che è veramente lei, se sul profilo ha link verificato al sito di fff, per esempio).
Prossima volta che ci becchiamo voglio un nobel al gorgonzola però :)

[-] [email protected] 2 points 10 months ago

@oloturia @mike @informatica

> Mastodon riguarda riprendersi il possesso dell'infrastruttura, per fare in modo che non esistano "canali suggeriti per te" ma interazioni umane.

Sempre meno, con la super centralizzazione indotta verso mastodon.social e le istanze più grosse, e dopo l'introduzione di post di tendenza, account di tendenza, hashtag di tendenza, notizie di tendenza, attiva per default, disattivabile dallə admin (con l'eccezione degli account di tendenza), lasciata attiva ovviamente dalla stragrande maggioranza delle istanze.
Anche per questo, oltre che per tanti altri motivi (https://mastodon.help/#Critique e se vuoi anche https://puntarella.party/@jones/111438223570858900) sarebbe bello se riuscissimo a scrivere un server activitypub come lo vogliamo, oppure forkare mastodon, con un team grossetto.

[-] [email protected] 1 points 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.

[-] [email protected] 1 points 10 months ago

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

[-] [email protected] 1 points 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.

[-] [email protected] 1 points 10 months ago

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

[-] [email protected] 1 points 10 months ago

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

[-] [email protected] 1 points 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)

[-] [email protected] 1 points 10 months ago

@NicholasLaney @oloturia @mike @informatica

...riscrivo meglio questo passaggio

> lo iato di cui dici, tra istanze piccole e istanze grossissime, però, non è che "negli ultimi tempi si sta sbilanciando verso la seconda"...

...è che l’1% delle istanze più popolate ospita l’86% dellə utentə, e il 10% ne ospita il 99% (https://mastodon.help/basket/MastodonInstancesByUsersCount.ods), perché 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.

[-] [email protected] 1 points 10 months ago

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

view more: next ›

jones

joined 1 year ago