[Ninux-Calabria] Appunti riunione romana "Ninux 2.0"

[Stefano De Carlo]

Ciao a tutti,

Domenica 25/11 a Roma c'è stata una riunione battezzata "Ninux 2.0", con
lo scopo di far uscire fuori la strada verso cui far evolvere Ninux.
Anche se la riunione è stata visibile in streaming, era diretta
"soprattutto alla comunità romana" (parole loro).
L'obbiettivo è far uscire un documento (RFC) da commentare/sistemare che
descriva il risultato della riunione. Questo documento non è ancora uscito.

Si è parlato di: community, utilizzi di ninux, cose su cui concentrarsi,
obbiettivi, nuove direzioni, mezzi di comunicazione, condivisione
connettività, provider condiviso, infrastruttura fisica, rete overlay,
nuova linfa, e altro ancora.

La riunione la trovate registrata integralmente qui:
https://www.youtube.com/watch?v=S_iuUfwnlqM
Qui invece gli appunti "ufficiali" presi durante la riunione:
https://pad.ninux.org/p/ninux2.0 (inclusa la chat con cui sono
intervenuti in diretta altri ninuxer italiani)

Siccome mi rendo conto che quasi 4 ore di video non è cosa guardarli, ma
comunque sono state dette delle cose importanti sulla/per la rete, spero
di agevolare quanti più ninuxer possibili con una trascrizione dei punti
che ho reputato più salienti. Dove possibile c'è un rimando al tempo nel
video, se volete estrarre parti della riunione da guardare.

Un po' di mani avanti
- il video l'ho visto una sola volta, prendendo gli appunti mano a mano.
Non penso di aver travisato nulla di macroscopico, ma potrebbe essere
successo
- nel qual caso spero nessuno dei romani presenti la prenda sul
personale, non lo è :-)
- la trascrizione non è un sostituto della visione del video, che è la
sola cosa che fa fede
- la trascrizione non ha pretese di completezza, è giusto per dare
un'idea dei contenuti e fornire dei puntatori
- la scelta di cosa trascrivere e cosa no è basata su quanto chiara era
la conversazione + su quanto relativamente "importante" ho reputato quel
passaggio
- in ogni caso scelte tutte a mia discrezione

L'unico "contesto" che penso sia necessario fornire è sulla cosiddetta
"rete overlay", che penso non tutti i ninuxer conoscano come progetto.

Essenzialmente finora Ninux è stata una rete fisica, fatta di link
wireless messi su e di proprietà di noi ninuxer.
Il vantaggio è una rete con piena autonomia. Lo svantaggio è che dove
non arriva il wifi Ninux, non si entra nella rete Ninux.
Questo però ad un circolo vizioso dove
- un nodo vuole diventare attivo, ma
- non ha nessuno a cui collegarsi fisicamente
- quindi non monta il nodo, aspettando qualcun altro
- qualcun altro vuole diventare attivo, ma
- [ciclo infinito]

Un'idea per interrompere questo circolo vizioso è quella di creare un
sistema dove chi vuole entrare in Ninux (comunicare con altri Ninuxer),
ma è dotato solo di connessione a Internet, può farlo attraverso una
sorta di VPN comunitaria.
Si chiama rete overlay perché (parte di) Ninux viene "disegnata sopra"
(overlay) Internet.
Ovviamente fare una rete del genere cambia parecchio la natura di Ninux,
e ci sono tante opinioni su come tecnicamente e organizzativamente fare
questa cosa, tutte con vantaggi e svantaggi. A Roma nella riunione è
emersa una prospettiva su questo progetto e altro ancora.

Chiedo a tutti per quanto possibile di buttare almeno un occhio agli
appunti, così da ragionarci assieme.

Happy Meshing,
Stefanauss

-------------- parte successiva --------------
= RETE OVERLAY =

* 04:30     Al Ninux Day c'eravamo detti di spingere sulla rete overlay (RO)
* 12:30     Discussione sui requisiti per l'accesso alla RO
* 16:30     La trustness per l'accesso consiste in una presentazione in lista
* 21:00     Se entri nella rete (fisicamente o da RO), o dai transito (sul modello dei calabresi) o dai servizi
* 25:10     Con la RO non hai più il vincolo geografico
* 32:00     Ha senso il requisito di localizzazione sul map server (MS) per la RO?
                - Clauz: i nodi VPN sono nodi fisici potenziali, quindi si
* 36:00     Va sviluppata una policy di transito per i nodi misti VPN/Wireless
            Potrebbe essere consentito il bandwidth shaping della connettività in uscita per i nodi VPN

== SERVIZI 1 ==

* 45:00     Lo sharing della connessione a Internet è un discorso personale, non (va indirizzato a livello) comunitario
* 56:20     Eccezione: Roma come tunnel broker IPv6 per il resto per la community
* 57:20     FabSys, Nino e Sal stanno lavorando alla rete LoRA
* 58:30     Identifichiamo un minimo di servizi comuni su cui focalizzare gli sforzi
* 1:00:00   Incontrarsi è sempre più difficili, cerchiamo di realizzare mini-task applicabili (singolarmente, asincronamente?)

= COMUNICAZIONE 1 =

* 1:01:01   Sal faceva notare che le ML hanno traffico praticamente nullo
            FLM: le persone andrebbero educate/istruite su come utilizzare appropriatamente i mezzi di comunicazione
            Senza subject è impossibile focalizzare l'attenzione

= INFRASTRUTTURA FISICA =

* 1:08:00   Nino: fare il wireless va fatto dove ha senso, in una zona periferica ad esempio, ma dentro Roma no
* 1:18:00
- Stiamo ignorando volutamente l'infrastruttura fisica, anche perché ormai almeno dentro Roma tutti hanno la 100 mega.
- Oltretutto non tutti sono interessati all'infrastruttura fisica, vogliono operare sulla parte applicativa.
- Svingolare i paradigmi Ninux dalla rete fisica potrebbe allargare gli orizzonti della rete, e ristimolare l'interesse.
- Nino: non serve più il wireless per condividere in modo decentemente simmetrico
- Il link fisico può essere utile per backup, emergenze, ma non è più il "divertimento principale"
- 1:20:00 FLM: Se sposti il focus dal link fisico, poi però diventa no provider = no ninux
- Nino: Noi abbiamo un AS, abbiamo IPv4/v6 pubblici, abbiamo (punti?) fisici, possiamo crearci una nostra RO a prescindere dalla connettività

== SERVIZI 2 ==

1:29:00
- Nino: possiamo costruire un'alternativa diversa ai cloud commerciali
- FabSys: best effort si, ma "che sai che funziona"
- Nino: non ci possiamo mettere a sostituire Internet
1:31:40
Nino: siete d'accordo a spostare il focus della rete sui servizi distribuiti?

= FORMAZIONE NINUX =

* 1:33:15   Nino: "Preferisco che la gente non ci segua più perchè è difficile farlo, piuttosto che gli venga facile farlo ma non venga spronato a evolvere. Poi non è detto che tutti debbano essere esperti di rete e IP..."
* 1:36:20   FabSys: la pappa pronta non ha mai funzionato; Andrea: i  freifunk però la pappa pronta ha funzionato; Nino: anche loro hanno cambiato negli anni
* 1:37:50   FabSys: interroghiamoci sul perché stiamo qua, perché non abbiamo niente di meglio da fare a casa? Molte cose che faccio a casa hanno inerenza in Ninux, ma preferisco farle assieme ad altri; Nino: se non fossimo una rete di persone che senso avrebbe un'antenna sul tetto, che ci fai? Il punto è che siamo un gruppo che si vede, che collabora per avere una cosa in più rispetto (alle potenzialità dei) singoli individui
* 1:39:45   FabSys: Ninux non è la copia del progetto freifunk, non ci va di fare quelle cose

= DOCUMENTAZIONE 1 =

* 1:47:40   Per la documentazione, passare a Markdown, ReadtheDocs, roba committabile
* 1:49:00   Trasferire il blog Ninux, passare allo statico. Idea jekyll, stessa filosofia di RTD applicata ai blog. Si potrebbe applicare questa cosa al map server, descrittori json/yaml sparati da un motore su una pagina web

= CHE COMMUNITY =

* 1:54:10
Clauz: Un nodo che sta venendo fuori è che facciamo questa cosa per divertirci e che siamo una community di nerd. Non è vero che l'abbiamo sempre detto, non tutti (nella community la vedono così)
Nino: Non è vero che è solo per divertimento. Anche fare cose utili per gli altri. Magari c'è una cosa più utile di questa, ma non ci va di farla, non la facciamo. Si tratta di incanalare questo piacere a fare una cosa, nel farla utile. Secondo me le due cose non collidono.
Clauz: Ma sappiamo che c'è un lato della community, almeno fuori Roma, che non la vede così.
FLM: Le Marche sono fallite perchè si sono condivisi la connettività e basta.

= PROVIDER COMUNITARIO =

* 1:58:30
Andrea: Tutti hanno Telecom. Ma se fossimo 1000, avremmo tipo 40k € e invece di darli a Telecom...
Clauz: Stai cercando di fare una cosa etica che costi meno di una cosa commerciale, e non è possibile
FabSys: Questa cosa non regge, nel momento in cui fai un discorso di provider condiviso, nel momento in cui metti in mezzo i soldi, tutto non funziona più, perdi il discorso del best effort
Nino: Telecom è meno costosa di qualsiasi rete Ninux, banalmente per una questione economica di scala. Se tutte le persone che sono dentro Ninux avessero la connettività Ninux, gli costerebbe molto di più, il doppio...
Andrea: Magari con il contributo di tutti i partecipanti (non sarebbe così)
Nino: Chi dovrebbe manutenere la rete? Delle persone pagate per farlo.
Andrea: Se lo fai come vendita...
Nino: No, se fossimo solo questi, chi la fa funzionare? Più la rete è grossa più c'è bisogno di gente che "sta là". Un operaio in Ninux ti costerebbe più di un operaio Telcom banalmente per una questione di economia di scala. Chi vuole fare così lo faccia, come ha fatto Palestrina, ma io non credo che abbia funzionato questa cosa. E se funziona bene, funziona solo in piccole realtà dove non c'è alternativa.
Andrea: o quella in Piemonte.
Nino: Quella è un'altra cosa, perché chi la gestisce là? Gli studenti universitari, che a rotazione da quando si laureano per un po' di mesi si fanno le ossa, ma se si interrompe la rotazione?
FabSys: Chiariamo una volta per tutte che non siamo un ISP comunitario, chi ha voluto si è fatto il proprio progetto, Ninux non vuol far questo.
Nino: Il nostro interesse non è mai andato in quella direzione, anche perché per fare queste cose devi strutturarti e anche questo è contro il nostro modo di vedere distribuito in cui non ci può essere il Presidente dell'associazione Ninux che si prende la responsabilità
FabSys: Lavorare strutturati è una fatica, la maggior parte dell'effort se ne va per far funzionare la struttura.

= STRUMENTI DI {COMUNIC,DOCUMENT}AZIONE =

2:08:00

Clauz: Io spiegherei la logica della questione forum
Nino: Secondo me in questa fase la logica non deve essere "se vuoi farti il forum te lo fai". Non va proprio acceso. Accentua la frammentazione della comunicazione, non riusciamo più a comunicare bene
FabSys: Cerchiamo in questa fase di darci delle policy di autoregolamentazione
[segue discussione sui pro e contro dei singoli strumenti di comunicazione]
Daniela: Se non ci fosse più questo canale, tutti saremmo obbligati ad utilizzare la ML
Nino: Dobbiamo essere coscienti che usando alcuni strumenti ad alcuni le informazioni non arriveranno (e che quindi li stiamo escludendo). La mail ce l'hanno tutti.
Clauz: Telegram è nato per facilitare i nuovi
Nino: Ma sempre con quel modo di vedere che gli devo fare avere la pappa pronta. È quello che secondo me è un po'...
Clauz: Su Telegram scrive chi ha tempo, quindi va a finire che i nuovi parlano ai nuovi, e quella cosa del "tutoraggio" che c'era all'inizio viene a cadere completamente.
Nino: Fare il log massivo di Telegram/IRC, a che pro? Sembra na follia.
Nino: Il wiki è una documentazione pensata per essere sempre fruibile. La ML è una comunicazione asincrona.
Nino: Io il canale Telegram non l'ho mai letto. Secondo me Telegram non serve proprio, a parte per le cazzate.
2:26:00 - Quindi la questione è avere autodisciplina Noi
Nino: Io sarei per spegnere tutte le liste locali, rimane solo -wireless
FabSys: Io espliciterei dei casi d'uso appropriati per i vari strumenti di comunicazione
FLM: Una volta fatte delle guide, la prima cosa che si dice è "vatti a vedere la guida". In più andrebbe migliorata la documentazione in base a quanto scritto in chat
2:39:00 Nino: Uno strumento non deve avere immediatezza, dev'essere lo strumento giusto. Poi se non è immediato, sticazzi, si impara ad usarlo. [L'idea che] se crivi li, ti serve la risposta lì, è sbagliata proprio.
2:42:00 - Se la documentazione deve essere fatta, deve essere di qualità e strutturata. Per me sistemi tipo Q&A producono solo info di bassa qualità e non impari mai.
2:46:00 - FabSys: questo gruppo sta morendo anche perchè mancano le competenze. Quelli che montavano le antenne, erano sempre le stesse persone, ecc
2:48:00 - FLM: Come usare e scrivere la documentazione Ninux, deve essere la guida 0.
2:49:00 - Ci vorrebbe un sistema di revisione dei contributi alla documentazione, il wiki Ninux al momento non lo supporta
2:51:30 - FLM: Chat, ML, Wiki non devono avere punti di contatto perchè assolvono a tre scopi diversi
2:55:00 - Nino: considerate che la situazione del Mail Server è critica perché sta su una macchina vecchia e non si può toccare
3:12:00 - Dal 2014 al 2018 la pagina guide è passata da 1800 accessi a 157

== MAP SERVER ==

3:21:00 - Situazione Map Server: map.ninux.org (Nodeshot v0.9) è vecchio e ogni 2 per tre si spacca il db; Nodeshot v2 non è più mantenuto; NNXX/OpenWISP non ha la parte map server. Che famo? 
- Su v0.9 ci vuole una API key per ripristinare le mappe google, e qualcuno deve sacrificare una carta di credito
Nino: Possiamo andare verso quella cosa che dice Clauz implementandola su git. Sticazzi dell'interfaccia di inserimento, ti impari a farlo su git.
Nino: Facciamo la cosa più semplice che non dobbiamo mantenere solo noi, sennò va a morire
Clauz: idea LibreMap di Altermundi