💾 Archived View for koyu.space › zuz › glog › un-protocollo-di-im-810.gmi captured on 2023-04-26 at 13:19:55. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
Posted by bu on Wed, 02 Feb 2022 14:59:03 +0100 in “Privacy”, “Smanett” and tagged with “Instant messaging”, “Peer-to-peer”
Last modified on Sat, 05 Nov 2022 17:04:44 +0100
Dato che uno scambio di dati che sia davvero peer-to-peer (che avvenga cioè tra due dispositivi senza passare attraverso altri dispositivi) su internet non avviene praticamente /mai/ (vedi la figura qui sopra), e dato che comunque anche il “peer-to-peer” come lo intendiamo comunemente è sempre meno praticabile (su connessioni mobile è un delirio, perché i provider di connessione mobile non permettono – se non pochissimi e comunque tramite sbattimenti burocratici non indifferenti da parte dellə utentə – di avere un indirizzo IP pubblico sulla internet), e dato che comunque un server di relay che stia tra i client viene comodo per registrarci sopra i messaggi crittati end-to-end quando un@ dellə utentə destinatariə di un messaggio è offline, e al tempo stesso, grazie alla crittografia end-to-end, può essere altrettanto sicuro di un’immaginaria connessione /realmente/ peer-to-peer tra client, e dato che la crittografia end-to-end sarebbe comunque necessaria per la privacy dellə utentə anche con il “peer-to-peer” come comunemente inteso, mi chiedo se non sarebbe fattibile un protocollo di instant messaging basato su server federati, in cui la crittografia end-to-end non è opzionale, in cui però l’id univoco di ciascun utentə non è legato a un particolare server-dominio, in cui lə utentə scambiano dati tra loro passando attraverso i server federati e /sono i server federati a fare “peer-to-peer” tra loro/ sincronizzando un database distribuito con una tabella che contiene l’id e la chiave pubblica di ciascun utente (mentre quella privata rimane sempre sui loro dispositivi), più l’indirizzo IP del server su cui ciascun utente è loggat@ (se è loggat@, altrimenti NULL), e un’altra tabella che contiene gli indirizzi IP dei server federati e il loro stato (tipo un numero da 0=offline a 9=“non mi sta usando nessun*”), così che se un server va giù per qualsiasi motivo lə utentə possono continuare a scambiare dati attraverso gli altri server senza interruzione di servizio e senza che, se poi quel server non torna più su, debban fare un nuovo account su un altro server e comunicarne il nuovo id a tuttə l’altrə, e così che il carico di utentə sia sempre abbastanza equamente distribuito tra i server. Ogni release di un client dovrebbe includere la lista dei server disponibili al momento della sua compilazione, così che il bootstrap di ogni sessione del client sia facile per l’utentə (poi il client scaricherebbe periodicamente la lista aggiornata dei server dal server cui è connesso). Per l’anonimato, i client dovrebbero potersi collegare ai server tramite Tor. Il sito di presentazione di questo protocollo, e tutti i vari siti coinvolti, dovrebbero mettere in chiaro che, lato server, non deve essere reso disponibile via web, e che, lato utente, non deve essere utilizzato via web, quand’anche qualche server desse questa possibilità .
Mi chiedo se non sarebbe fattibile.
Converted with wp2gem v0.2.6 on Sat, 05 Nov 2022 19:35:08 +0100