Ciao Giacomo, care nexiane: scusate se entriamo così in dettaglio in questioni tecniche però vorrei che questa discussione fosse a disposizione di coloro che desiderassero approfondire un minimo. In sintesi, per chi volesse saltare il resto, il succo del mio discorso è che i "sistemi distribuiti" sono molto diversi dai "sistemi federati" e questi ultimi, pur incoraggiati da norme antitrust, non risolvono il problema della concentrazione oligopolistica delle risorse da parte di pochissimi e ricchissimi intermediatori. Giacomo Tesio <giacomo@tesio.it> writes:
Scusa Giovanni ma non mi è chiaro cosa intendi:
capisco, spero di riuscire a spiegarmi meglio allora...
On January 23, 2021 11:07:00 PM UTC, Giovanni Biscuolo wrote:
*se* vogliamo che "il messaggio" (non solo social) raggiunga potenzialmente miliardi di destinatari.
Un sito Web servito via HTTP (senza TLS) può tranquillamente raggiungere miliardi di destinatari senza problemi grazie alle cache intermedie.
HTTP ha bisogno di cache intermedie e quindi al massimo può essere distribuito con una architettura _distribuita_ (pun intended) perché è un protocollo unicast [1] (o al massimo anycast che è analogo): trasmissione uno-a-uno. Quello di cui parlo io (o meglio Carlo von Lynx et al) è un protocollo tipo PSYC (Protocol for Synchronous Conferencing) https://secushare.org/scalability#sec-1 che sia *inglobato* in uno strato di protocolli di rete che effettuino il routing e il caching garantendo l'anonimato dei partecipanti alla trasmissione (GNUnet) e consentano il multicasting https://en.wikipedia.org/wiki/GNUnet#Social_API. Una "roba" relativamente vecchia (nel 2001 symlynX usò un prototipo di PSYC per un'intervista in webchat organizzata da MTV) e poco conosciuta ma che **mi pare** progettata da persone che sanno il fatto loro. Per essere chiari: ancora tutto a livello di prototipo e AFAIK il multicastoing è forse ancora in stato embrionale... ma può funzionare. Sempre gli amici di secushare.org, invece, sostengono che nella "community degli standard" la questione del multicasting sia largamente ignorata: https://secushare.org/scalability#sec-3 --8<---------------cut here---------------start------------->8--- We have been warning about the importance of addressing scalability upfront in both the federated and the distributed networking worlds, and yet standards are being written that simply do not take the problem into account. Both new 'social web' standards do not provide means for scalable delivery of events [...] The outcome of this is that these new standards only work for small communities or for cloud-based systems. Scaling up to a use for the whole human race without centralization becomes near impossible. There is plenty of scientific work documenting the importance of serious distribution strategies, yet the protocol design community continues to have a blind spot in that regard, seven years after we presented "Scalability & Paranoia in a Decentralized Social Network" at a Federated Social Web conference. --8<---------------cut here---------------end--------------->8--- La pagina web citata sopra fornisce ulteriori puntatori se del caso, tra cui questo: https://secushare.org/centralization «The Power of Centralization» dal quale cito solo questo brevissimo estratto: --8<---------------cut here---------------start------------->8--- We're now in wave 3 of attempts to decentralize personal data. Wave 1 was in the late '90s; the companies called themselves "infomediaries". […] --8<---------------cut here---------------end--------------->8--- giusto per dare l'idea del contesto (anche) storico al quale ci stiamo riferendo. [...]
Non voglio essere petulante, ma rischiamo di confondere i non-informatici
Mi spiace se ho contribuito a confonderli: la materia è tecnica e purtroppo tocca usare un po' di termini tecnici per spiegare concetti oggettivamente complessi e parzialmente ignorati anche dagli addetti ai lavori. Attualmente i sistemi p2p NON sono in grado di reggere il confronto con quelli centralizzati o federati: Jami, Tox.chat o qualsiasi altro sistema p2p non consentono di creare "gruppi" di migliaia di partecipanti se non al prezzo di una latenza inaccettabile per una comunicazione analoga a quella "dei social", peggio per applicazioni video. Telegram, Signal, Whatsapp ecc sono centralizzati (e sparsi su enne data centre inteconnessi, una sorta di autofederazione) per una valida ragione tecnica.
la centralizzazione che causa problemi non è infrastrutturale, ma solo amministrativa.
Secondo me (e non solo me) sì. :-D
Internamente l'infrastruttura di queste enormi aziende è già distribuita e federata ed è proprio per questo che riescono ad avere miliardi di utenti.
Esatto: che sia centralizzata in un unico data centre o federata in ennemila data centre, riusciamo a raggiungere potenzialmente miliardi di utenti perché per ora abbiamo a disposizione SOLO protocolli unicast (o anycast al massimo e tra l'altro quelli non sono proprio alla portata di tutti) che ci permettono al massimo di distribuire i servizi su più data cenre e federarli con protocolli "a rappezzo" della mancanza di multicast. Quindi è un problema di (mancanza di) protocollo a livello di application layer; i protocolli unicast con applicazioni più o meno federate (o più o meno centralizzate, è quasi uguale) non risolveranno il problema del controllo tecnico-amministrativo oligopolistico: le economie di scala, in special modo in regimi capitalisti che perseguono la massimizzazione dei profitti e la minimizzazione dei costi (QUALSIASI voce di costo), tenderanno SEMPRE all'aggregazione e quindi al controllo centralizzato.
Il problema in questo momento non è tecnico, ma politico: è solo chi controlla i server (il centro del sistema centralizzato), non dove si trovano o come comunicano.
Noi (plurale minoritaris) riteniamo che invece il problema sia meramente tecnico e non vediamo l'ora di liberarcene una volta per tutte perché poi l'unico modo per controllare la circolazione in rete dei messaggi (che veicolano informazioni) sarebbe quello di vietare la distribuzione del software... ma fa fare brutta figura no?!? :-D
Poi non devi certo convincere me dell'importanza di riscrivere Internet, ma in questo momento il problema che abbiamo davanti è semplice: queste aziende sono un cancro in continua espansione.
Bisogna ridurlo.
Non devi convincere me che questi oligopoli sono un problema (non userei la parola cancro perché li fanno apparire fisiologici) e occorre eliminarli; tuttavia mi perdonerai se io (e non solo io) non nutro **alcuna fiducia** che problemi di una simile portata - anche tecnica - possano essere ridotti o eliminati con adeguate legislazioni: (mi autocito https://server-nexa.polito.it/pipermail/nexa/2021-January/020048.html) --8<---------------cut here---------------start------------->8--- A meno che si vogliano trascorrere i prossimi vent'anni a discutere ancora di come regolamentare il funzionamento di un Panopticon, che Panopticon rimarrà comunque lo si giri. --8<---------------cut here---------------end--------------->8---
In fretta.
OK, allora tutto sta a decidere come si fa più in fretta **ma** il problema va risolto sul serio, non "pittato" di nuovo. Ciao, Giovanni. [1] https://en.wikipedia.org/wiki/Multicast -- Giovanni Biscuolo