Ciao Marco, una paio di considerazioni generali. 1. nell'esposizione sono stato un po' superficiale senza entrare troppo nel dettaglio, andrebbe sviluppato il tutto. 2. stiamo usando un gergo che dice qualcosa solo ai cosiddetti addetti ai lavori: tutto andrebbe analizzato, aggiustato e sviluppato in modo da essere comprensibile a tutti i cittadini in modo che sappiano in che ambiente si stanno muovendo e quali sono i loro diritti. La diffusione della cultura informatica aiuterebbe moltissimo su tutti i fronti, ci eviterebbe di dover scrivere un trattato di informatica e telecomunicazioni in una norma, rendendola sostanzialmente inapplicabile. "M. Fioretti" <mfioretti@nexaima.net> writes:
Grazie Giovanni e solo una cosa, per il momento:
On Thu, Jan 21, 2021 01:40:59 AM +0100, Giovanni Biscuolo wrote:
2.1.c. Portabilità dei dati: obbligo a fornire tutti i dati in un formato non binario e documentato per consentire la migrazione ad altri intermediari.
forse e' solo che non ho ancora fatto colazione, ma mi sembra che qui manchi, almeno in forma esplicita, una cosa fondamentale senza cui la totale portabilita' dei dati non serve assolutamente a niente: la cosiddetta "adversarial interoperability".
Hai perfettamente ragione, ho sbagliato a inserire il requsito come 3.1.a: --8<---------------cut here---------------start------------->8--- 3.1.a Per i servizi 3.a: no controllo esclusivo delle interfacce per consentire a terzi di costruire interfacce interoperabili. --8<---------------cut here---------------end--------------->8--- Il requisito deve essere per la categoria 2, è il requisito più importante per tutti i servizi forniti da intermediari, adattato così: --8<---------------cut here---------------start------------->8--- 2.1.a Per tutti i servizi di intermediazione: no controllo esclusivo delle interfacce per consentire a terzi di costruire interfacce o servizi interoperabili. --8<---------------cut here---------------end--------------->8--- Per chiarire: con interfacce non mi riferisco solo quella web, ma in generale ad _almeno_ una di queste API: librerie, protocolli di accesso remoto, API web. Se si distribuiscono librerie queste devono essere software libero, il resto (protocolli, web API) deve essere documentato e liberamente reimplementabile. Le API web o i protocolli DEVONO esporre TUTTE le funzionalità del servizio, vietato fare i furbi. Sta al fornitore scegliere quale tipo di mezzo usare per garantire interoperabilità, ma questa DEVE essere garantita in questi termini. Sul formato di serializzazione del payload sarei liberale B-) e ciascuno scelga XML, JSON, s-expressions o PSYC [1] in funzione di quelli che ritiene tecnicamente adatti al proprio caso d'uso. Chi ha osservato come ha funzionato il mercato di questi servizi di intermediazione negli ultimi 25 anni comprende il significato _dirompente_ di regole siffatte... e imprese alternative potrebbero tornare a poter operare sul mercato degli intermediari, finché ci sarà. [...]
Esempio concreto: Facebook DEVE fornire TUTTE le notifiche e i feed COMPLETI di tutti i post di contatti, gruppi eccetera, anche via RSS o email. E DEVE permettermi di scrivere messaggi in ognuno di quei gruppi con API non proprietarie.
...oppure fornire il software libero (basta una libreria) per consentire ad altri di istanziare servizi alternativi _e_ migliorare e innovare il servizio, come succede con moltissimi "social" federati. Facebook fornisce servizi di CMS e instant messaging, è un intermediario. Pensate a cosa succederebbe se X (prendete X a caso tra il software libero "social" disponibile) avesse un "plugin" per federarsi con l'istanza Facebook :-O A meno che Facebook non scelga di diventare "editore" (editori di instant messaging?!? boh) e allora si applicherebbero regole di classe editoriale con tutto quello che ne con segue, vero?!? ;-) Non ci sono vie di mezzo: un intermediario non deve essere anche editore. Punto. Stessa _identica_ cosa vale per tutti gli altri "social" sul mercato: Twitter, Whatzapp, TikTok, Instagram, ecc. ecc. ecc. [...]
Pochi anni dopo, facebook ha rimosso quelle API dalla sera alla mattina.
Stessa cosa con Whatsapp, cosa analoga con Google Messanger o comecavolo si chiama che ha mollato lo standard XMPP dopo essere _quasi_ riuscita a renderlo non interoperabile (vado a memoria, potrei sbagliarmi). Per fare un esempio alternativo, Telegram risolve la cosa in modo brillante con la libreria (interfaccia, API) tdlib https://core.telegram.org/tdlib distribuita con licenza Boost 1.0 [2] (non copyleft GNU GPL compatibile); con quella libreria ci si connette a Telegram perfino da Emacs, chat crittografate comprese, per soddisfare le esigenze di quelli come me :-D... per tutti gli altri ci sono app alternative per smartphone o software "desktop" per PC. Tra l'altro quella di mettere a disposizione le API come libreria è la soluzione migliore _anche_ per il fornitore del servizio che si leva dalle scatole d'un botto tutta la menata di dover progettare, mantenere e _documentare_ protocolli remoti o API web. Ognuno scelga l'API sua, basta che paghi lui lo sviluppo e il mantenimento "dell'ambaradan" fatto secondo le regole suddette. In altre parole la libreria in software libero è contemporaneamente reference implementation, documentazione completa del protocollo di comunicazione e dei formati dati e infine documentazione completa delle API per l'accesso remoto: costa meno (perché comunque il software bisogna scriverlo) e può essere sviluppata e manutenuta collaborativamente distribuendo i costi, volendo. Questa è la forza del software libero.
E da allora tutti, a partire da politici e professoroni vari in tutto il mondo, hanno solo perso tempo cercando di risolvere
...partendo dalla coda e senza affrontare il nocciolo dei problemi, in funzione delle loro caratteristiche e collocazione all'interno di un "framework" di analisi. Invece così continuiamo a complicarci inutilmente la vita con interminabili discussioni sugli epifenomeni dell'infosfera (come definita da Floridi), che più passa il tempo più si trasforma in un World Wide West stile 1800. [...] Grazie per i commenti! Ciao, Giovanni. [1] https://secushare.org/protocol#sec-2 [2] https://en.wikipedia.org/wiki/Boost_(C%2B%2B_libraries)#License -- Giovanni Biscuolo