this post was submitted on 18 Nov 2023
13 points (100.0% liked)
Informatica (Italy e non Italy 😁)
1219 readers
11 users here now
Ecco finalmente la comunità italiana Lemmy dedicata all'informatica!
Questo è il luogo in cui condividere post sul mondo dell'informatica: notizie su hardware e software, cybersecurity, cyberwarfare, hacking, nuovi prodotti, data breach!
Ricordiamo che esistono anche alcune comunità che si occupano di argomenti più specifici, quali:
- Le Alternative, dedicata alle alternative open source ai prodotti più diffusi
- Etica Digitale, dedicata alle implicazioni etiche della tecnologia
- Pirati Europei, dedicata al mondo dei pirati italiani ed europei
- Che succede nel Fediverso, dedicata alle notizie sul fediverso
- Devol, con le notizie sulle istanze del fediverso e i servizi di decentralizzazione del collettivo Devol
- Lavoratori Tech, dedicata al tema del lavoro tecnologico
- Videogiochi, dedicata al gaming
- Retrogaming, per i videogiochi vintage
- GNU/Linux Italia, dedicata nello specifico al mondo del pinguino
Regole della comunità:
🏳️🌈 chiediamo educazione e rispetto per gli altri
🎃 anche se ci chiamiamo "Informatica" non banniamo gli utenti a caso 😁
🚫 trolling, shitposting e molestie sono vietati
💲 è vietato superare il confine che separa l'informazione dalla pubblicità
🔊 evitiamo il clickbait e il sensazionalismo
📖 per il resto valgono le regole dell'istanza al link https://feddit.it/post/6
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
@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)
@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.
@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.
@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.
@NicholasLaney @oloturia @mike @informatica
Sono sicuro che a smanettarci bene se ne caverebbe qualcosa di buono, mi vengono in mente tante altre possibilità.
@jones
Sì, ma a prescindere dal protocollo che usi, una foto caricata in america dovrà arrivare in europa.
Se la si tiene in database sarà trasmessa una volta sola, ma devo avere un db ampio, se la richiedo ogni volta andrà trasmessa spesso, e in db avrò solo roba locale, che a mia volta trasmetto.
E il grosso del traffico non sono le tabelle, ma i media.
E niente, ti è sfuggito il nobel pure oggi. ;)
@oloturia @mike @informatica
@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ò :)