Se sai già perché il permacomputing
e piccoli progetti come Snac sono importanti per il fediverso,
salta pure alle istruzioni per l'installazione.
Questo articolo è disponibile anche in inglese.
Il Fediverso è una federazione di comunità che funziona più o meno come un grande social network, ma senza autorità centrali o il controllo algoritmico di credenze e comportamenti delle persone che alimenta il "capitalismo della sorveglianza".
Il Fediverso collega applicazioni differenti che comunicano attraverso alcuni protocolli (il più diffuso dei quali è ActivityPub), fornendo servizi differenti utili a comunità differenti.
Una (piuttosto limitata) lista delle applicazioni che il Fediverso può connettere.
Data le sue radici acare e l'attenzione alla comunicazione fra comunità diverse, l'esperienza tipica del fediverso è piuttosto particolare, se confrontata con quella fornita dai social network commerciali.
I contenuti sono distribuiti agli utenti in un ordine strettamente temporale, per cui è piuttosto raro che un contenuto diventi "virale" nello stesso modo in cui ciò può avvenire su piattaforme come X, Facebook o TikTok, dove la piattaforma pompa la diffusione di determinati contenuti presso persone vulnerabili per aumentarne la dipendenza psicologica dalla piattaforma o per orientarne opinioni e scelte.
Nel fediverso trovi principalmente persone che pensano ai fatti propri, che chiaccherano con amici conosciuti in carne ed ossa, che condividono i propri contenuti e ogni tanto ingaggiano conversazioni interessanti con sconosciuti.
In altri termini, il Fediverso è orgogliosamente strambo.
Il pesce grosso mangia i pesci piccoli tutti
Dagli albori di identi.ca, il Fediverso è cresciuto, evolvendo in un sistema composto da migliaia di comunità differenti che gestiscono il proprio nodo (comunemente chiamato "istanza") con le proprie applicazioni preferite.
Millioni di persone appartengono a tali comunità e scambiano quotidianamente le proprie opinioni, contenuti e stati d'animo attraverso il sistema. Molte di queste comunità sono aperte a nuovi membri che ne condividano interessi specifici o valori, o magari che desiderano semplicemente partecipare al dibattito pubblico fuori dal recinto controllato da miliardari statunitensi.Nel corso degli anni, alcune istanze generaliste sono cresciute così tanto da minacciare (volontariamente o meno) l'autonomia dell'intero ecosistema. Un problema esacerbatosi quando Meta (proprietario di Facebook, Instagram e WhatsApp) ha connesso Threads, la nuova app che persegue la consueta tattica BigTech del "embrance, extend and extinguish".
"Meta proposing Threads to the Fediverse" di David Revoy.
I problemi cibernetici che da istanze con milioni (o miliardi) di utenti impongono alle comunità più piccole sono sia tecnici (aumento del carico del server e dunque dei costi) e socio-politici (molestie, spam, sfruttamento algoritmico delle persone...) ma la loro analisi occuperebbe troppo spazio in questa (già lunga) introdudizione ad una delle possibili soluzioni.
Basti dire che molte istanze di grandi dimensioni sono state ben felici di accogliere Threads dopo l'introduzione di Rocho.
"Don't roll out the red carpet for them" di David Revoy.
Pseudo-decentralizzazione
Un pericolo differente e più subdolo è la "pseudo-decentralizzazione".
L'esempio più chiaro ed evidente è BlueSky, un social network commerciale che si finge decentralizato, mentre di fatto rende "Bluesky Social, PBC" un gatekeeper in condizione di decidere cosa ciascuno possa leggere.
Ma una forma più subdola di "pseudo-decentralizzazione" è causata
da grandi fornitori di istanze gestite come masto.host
o toot.io: è bello vedere
fornitori professionali di applicazioni connesse al fediverso, ma il loro
utilizzo da parte di istanze con centinaia o migliaia di utenti
riduce nettamente la resilienza del sistema e l'autonomia delle comunità più piccole.
E se ti lamenti troppo dei rischi che queste aziende pongono
per i dati personali degli utenti, verrai presto silenziato o
bloccato da quegli amministratori che non hanno le competenze
per amministrare in prima persona i server che forniscono agli altri.
Istanze Mastodon che fingono autonomia e indipendenza... ma che dipendono tutte dalla stessa azienda.
La forma peggiore di pseudo-decentralizzazione consiste però nel deployare le applicazioni sui servizi cloud delle BigTech (AWS, Azure e così via), che espongono gli utenti allo sfruttamento aziendale e alla sorveglianza statunitense sotto la rinnovata ed estesa FISA 702.
Se i BigTech possono accedere ai dati dei tuoi utenti, stai tradendo la loro fiducia.
Un amministratore di sistema appena appena competente... corrotto dal cloud provider che ha evocato.
Tutte le minacce sfruttano una singola vulnerabilità del sistema: il self-hosting di applicazioni è piuttosto complesso e costoso.
In generale, gestire un server esposto su Internet richiede competenze tecniche piuttosto elevate come amministratore di sistema.
Ad esempio, il self-hosting di un server Mastodon richiede risorse
(principalmente storage e banda) che crescono con il numero di utenti attivi,
dei loro follower e del numero di persone che seguono da altri server.
Se non puoi ospitare il server sul tuo hardware, un VPS europeo affidabile
per una comunità piccola ma attiva costerà più di 500€ l'anno.
Certamente non il passatempo più costoso del mondo, ma entrambi i requisiti (competenza e soldi) diventano barriere che scoraggiano molte comunità dal costruire il proprio spazio autonomo nel Fediverso.
Permacomputing al soccorso!
Fra i gruppi più insoliti che puoi trovare sul Fediverso c'è un gruppo di hacker sparso in tutto il pianeta che sta costruendo un'infrastruttura post-capitalista libera e sostenibile ispirata dalla permacultura.
Sono entrato in contatto con il permacomputing anni fa grazie a Bob Mottram,
l'hacker che ha creato LibreServer
e l'ottimo epicyon, e
che persegue gli stessi obiettivi che abbiamo qui, ma
in un modo differente (creare software adatti al self-hosting su hardware a basso consumo).
Tuttavia possiamo trovare applicazioni dei principi del permacomputing in molti software ben prima che tali principi fossero concettualizzati, come nell'Oberon Operating System o nel Fossil Software Configuration Management System.
Fossil in particolare ha ispirato lo sviluppo del mio doh.cgi, un filtro DNS-over-HTTPS che può essere eseguito come CGI in moltissimi web hosting economici.
L'obiettivo politico di doh.cgi è di sfruttare una tecnologia progettata per centralizzare la maggioranza delle risoluzioni DNS nelle mani di pochi cloud provider (con la scusa di proteggere la privacy degli utenti), per proteggere davvero i dati degli utenti.
Usando il vecchio ambiente CGI, ciascuno può crearsi il proprio filtro DNS-over-HTTPS per pochi euro l'anno, spesso entro i pochi megabyte di hosting web che molti fornitori includono gratuitamente nell'acquisto di un dominio.
Funziona così bene da convincermi che il buon vecchio framework CGI può essere usato per contrastare le forze centralizzanti che ammorbano il Fediverso, semplicemente perché ci sono molti più webmaster che amministratori di sistema competenti.
Coerentemente con i principi del permacomputing, prima di iniziare a sviluppare l'ennesima applicazione per il fediverso (sotto la mia solita Hacking License) ho cercato soluzioni esistenti da adattare allo scopo.
Il primo software che ho trovato è #Seppo, un brillante CGI scritto in OCaml che fornisce agli utenti una presenza personale sul Fediverso.
#Seppo è sviluppato amorevolmente da Marcus Rohrmoser con una filosofia che adoro e diverse decisioni progettuali che mi piacciono, ma è un po' troppo "hacker-friendly" per la maggioranza delle comunità, per cui non risolverebbe il problema politico che mi interessa affrontare.
SNAC: Social Networks Are Crap!
Successivamente ho trovato Snac un server ActivityPub semplice e minimalista scritto in C portabile da Grunfink, che si è dimostrato sufficiente evoluto da interagire in modo trasparente con i front-end Mastodon come Tusky, Fedilab o Tootle.
Sebbene meno noto di altri server del fediverso (Mastodon, Pleroma, Friendica, Lemmy...), Snac è già piuttosto usato.
Tuttavia, esattamente come tali server, è solitamente ospitato su hardware domestico o eseguito in una VPS nel cloud (auspicabilmente non presso i BigTech).
Essendo un nerd del C io stesso, sono rimasto stupito dalla qualità e dalla originalità del suo codice (e dalla sua coraggiosa assenza di tests 😱). Così ho provato per qualche notte a martellarlo fino ad eseguirlo come CGI. E ci sono pure riuscito... ma.
Se vuoi eseguire un binario eseguibile su un web hosting economico non puoi fare affidamento sulla disponibilità di una specifica versione della GLibC, per cui devi ripiegare sul linking statico. Come dovresti fare sempre, in effetti. :-)
Tuttavia Snac dipende da OpenSSL e curl, che insieme rendono il binario finale più grande di 5MiB: almeno 3 page fault con la consueta dimensione delle pagine su Linux x86_64.
Sono numeri che possono sembrare irrisori se comparato con la pesantezza dei software contemporanei, ma non lo sono a causa di come il web server interagisce con un programma CGI, avviando un nuovo processo per ogni richiesta HTTP ricevuta.
Ho provato ad esplorare soluzioni alternative a questo problema
ma tutte richiedevano un fork di Snac perché le modifiche erano
sparse e non facili da gestire con qualche #ifdef.
Tuttavia non volevo forkare Snac visto l'ottimo lavoro di Grunfink.
Alla fine mi sono reso conto che, poiché Snac supporta l'esecuzione come FastCGI, avrei potuto scrivere un piccolo CGI per avviare Snac (quando non in esecuzione) e inoltrare le richieste ricevute dal web server attraverso un socket unix domain.
E sorpresa!
Leggendo il codice dell'implementazione
originale di FastCGI, ho scoperto che tale programma esiste già! :-)
Tuttavia, poiché capire come compilare e configurare snac e cgi-fcgi per lavorare insieme ha richiesto alcune notti (principalmente perché pochi usano queste tecnologie oggi), ho scritto questo articolo per aiutare chi fosse interessato.
Cerco di assumere una familiarità con i sistemi GNU/Linux piuttosto basilare, con l'abilità di eseguire semplici comandi.
Compilare Snac
Ciò che segue (finalmente :-D) sono le istruzioni per compilare una versione di Snac e di cgi-fcgi linkate staticamente oltre che per installarle in uno shared hosting economico basato su Apache e GNU/Linux, creando un nuovo nodo del fediverso.
Queste istruzioni sono state testate su una Debian GNU/Linux ma dovrebbero funzionare su qualsiasi sistema operativo che disponga dei programmi necessari, anche su spyware come Windows (with WSL) o MacOS.
Anzitutto installiamo wget, tar, git, make, sshfs e musl-gcc:
sudo apt-get install wget tar git make sshfs musl-gcc
Useremo sshfs perché è più semplice da usare e documentare in una riga di comando, ma puoi facilmente adattare queste istruzioni ad una GUI come FileZilla: esegui i comandi localmente e poi carica tutto sul sito.
Prepariamo l'ambiente di lavoro:
mkdir deploy
cd deploy
export DEPLOY_TARGET=$PWD
cd ..
mkdir build
cd build
export BUILD_TARGET=$PWD
export CC="musl-gcc"
Scarichiamo e compiliamo le librerie necessarie, zlib, openssl, e curl:
echo download and build zlib
wget https://zlib.net/current/zlib.tar.gz
tar xvf zlib.tar.gz
cd zlib-1.3.1/
./configure --prefix=$BUILD_TARGET --static
make
make install
cd ..
echo download and build openssl
wget https://github.com/openssl/openssl/releases/download/openssl-3.4.0/openssl-3.4.0.tar.gz
tar xvf openssl-3.4.0.tar.gz
cd openssl-3.4.0
CC="musl-gcc -fPIE -pie -static -idirafter /usr/include/ -idirafter /usr/include/x86_64-linux-gnu/" \
./Configure no-shared no-async --prefix=$BUILD_TARGET --openssldir=$BUILD_TARGET/ssl linux-x86_64
make depend
make
make install
cd ..
echo download and build curl
wget https://curl.se/download/curl-8.11.1.tar.gz
tar xvf curl-8.11.1.tar.gz
cd curl-8.11.1
./configure --disable-shared --enable-static --disable-silent-rules \
--disable-debug --disable-warnings --disable-werror \
--disable-curldebug --disable-symbol-hiding --disable-ares \
--disable-rt --disable-ech --disable-dependency-tracking \
--disable-libtool-lock --enable-http --disable-ftp \
--disable-file --disable-ldap --disable-ldaps \
--disable-rtsp --disable-proxy --disable-dict \
--disable-telnet --disable-tftp --disable-pop3 \
--disable-imap --disable-smb --disable-smtp --disable-gopher \
--disable-mqtt --disable-manual --disable-libcurl-option --disable-ipv6 \
--disable-openssl-auto-load-config --disable-versioned-symbols \
--disable-verbose --disable-sspi --disable-crypto-auth \
--disable-ntlm --disable-ntlm-wb --disable-tls-srp \
--disable-unix-sockets --disable-cookies --disable-socketpair \
--disable-http-auth --disable-doh --disable-mime --disable-dateparse \
--disable-netrc --disable-progress-meter --disable-dnsshuffle \
--disable-get-easy-options --disable-alt-svc --disable-websockets \
--without-brotli --without-zstd --without-libpsl --without-libgsasl \
--without-librtmp --without-winidn --disable-threaded-resolver \
--with-openssl=$BUILD_TARGET/ --with-zlib=$BUILD_TARGET/ \
--prefix=$BUILD_TARGET/
make
make install
cd ..
NOTA che non sto fornendo uno script da eseguire per la stessa ragione per cui non sto rilasciando un paio di eseguibili pronti all'uso: ciascuna di queste dipendenze evolve nel tempo ed è tua responsabilità mantenerle aggiornate man mano che nuove vulnerabilità di sicurezza vengono scoperte e corrette.
Dopo di che possiamo compilare Snac:
git clone https://codeberg.org/grunfink/snac2.git
cd snac2
make CFLAGS="-g -Wall -Wextra -pedantic -static -DWITHOUT_SHM" \
LDFLAGS="-L$BUILD_TARGET/lib64 -lcurl -lssl -lcrypto -lz" \
PREFIX=$BUILD_TARGET
make install PREFIX=$BUILD_TARGET
(cd $BUILD_TARGET; strip bin/snac)
cd ..
Compilare CGI-FCGI
Il secondo strumento che ci serve è una versione linkata staticamente del venerabile CGI-FCGI:
git clone https://github.com/FastCGI-Archives/fcgi2.git
cd fcgi2
./autogen.sh
./configure --prefix=$BUILD_TARGET
make AM_LDFLAGS=-all-static
make AM_LDFLAGS=-all-static install
(cd $BUILD_TARGET; strip bin/cgi-fcgi)
cd ..
Configurazione
Ora che abbiamo i programmi che ci servono è ora di leggere la documentazione di Snac e in particolare il manuale di amministrazione.
Infatti stiamo per inizializzare il nostro nodo del fediverso.
Anzitutto dobbiamo connetterci al nostro web hosting, dove abbiamo
già creato un nuovo sito web vuoto con un certificato SSL
(oggi molti fornitori di shared hosting forniscono certificati
SSL gratuiti basati su Let's Encrypt).
Ovviamente devi sostituire "username", "ftpserver",
e "/your/new/website/folder" con i valori corretti.
sshfs username@ftpserver:/your/new/website/folder $DEPLOY_TARGET
Ora possiavo vedere il filesystem del nostro webserver nella cartella $DEPLOY_TARGET.
export PATH="$BUILD_TARGET/bin:$PATH"
cd $DEPLOY_TARGET
mkdir -p cgi-bin
cp $BUILD_TARGET/bin/snac cgi-bin
cp $BUILD_TARGET/bin/cgi-fcgi cgi-bin
snac init .snac-files
mkdir .snac-files/log
Nella cartella .snac-files troviamo il "database" del nostro nodo. Infatti Snac non usa un db relazionale, bensì file e hardlink fra di essi (che devono essere supportati dal filesystem sottostante)
NOTA che per ragioni di sicurezza, sarebbe saggio
mantenere binari, socket e la cartella di Snac fuori dal virtual host
(la directory servita ai visitatori del sito), ma questo potrebbe
essere possibile o meno a seconda del contratto sottoscritto.
Qui assumo che non possiate, per semplificare la spiegazione.
Ora dobbiamo personalizzare il .snac-files/server.json secondo le nostre esigenze. In particolare dobbiamo impostare la chiave "host" al dominio che abbiamo creato, la chiave "fastcgi" a "true", e la chiave "address" al percorso completo di uno unix domain socket che verrà creato per comunicare con il web server attraverso cgi-fcgi.
Per esempio, se il tuo nuovo dominio punta a /your/new/website/folder potresti impostare "address" a "/your/new/website/folder/snac.socket".
A questo punto possiamo aggiungere gli utenti:
snac adduser .snac-files alice
snac adduser .snac-files bob
...
Per ciascun utente dovremo appuntare la password iniziale per inviargliela tramite un canale sicuro e chiedere di cambiarla al primo login (e suggerendo l'uso di un password manager offline, come KeePassXC o KeePassDX).
Ora abbiamo bisogno di invocare cgi-fcgi per avviare il server Snac:
cat << EOF > cgi-bin/snac-wrap.sh
#!/usr/bin/sh
WEBSITE_ROOT=/your/new/website/folder
exec -c $WEBSITE_ROOT/cgi-bin/snac httpd $WEBSITE_ROOT/.snac-files >> /dev/null 2>&1
EOF
chmod u+x cgi-bin/snac-wrap.sh
Ovviamente se l'hosting provider non permette l'esecuzione di una shell, sarà necessario sostituire questo script con una alternativa equivalente, come uno script python o php o anche un piccolo programma C.
Questo script infatti verrà usato da cgi-fcgi per avviare Snac quando non è in esecuzione:
cat << EOF > cgi-bin/snac.cgi
#!/home/tesioic/tools/cgi/cgi-fcgi -f
-connect /your/new/website/folder/snac.socket /your/new/website/folder/cgi-bin/snac-wrap.sh 1
EOF
chmod u+x cgi-bin/snac.cgi
Infine, configuriamo Apache per invocare snac.cgi:
cat << EOF > .htaccess
# Se non viene fornito un percorso specifico, esegui cgi-bin/snac.cgi
Options -Indexes
DirectoryIndex cgi-bin/snac.cgi
# Evita i crawler e proteggi i dati degli utenti.
Header set X-Robots-Tag "noindex, nofollow"
Header set Referrer-Policy "no-referrer"
RewriteBase /
# Nascondi i file privati
RewriteCond %{REQUEST_FILENAME} .*snac-files.*
RewriteRule ^ - [R=404,L]
RewriteCond %{REQUEST_FILENAME} .*snac.socket
RewriteRule ^ - [R=404,L]
# Quando il percorso richiesto non esiste, esegui cgi-bin/snac.cgi
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule "^(.*)$" cgi-bin/snac.cgi [NC,PT,L]
EOF
cat << EOF > cgi-bin/.htaccess
CGIPassAuth on
Options +ExecCGI
SetHandler cgi-script
EOF
FATTO!
Il tuo nuovo social network è pronto ed in esecuzione.
L'interfaccia utente di Snac è piuttosto minimalista, ma puoi usarla con qualsiasi client compatibile con l'API Mastodon.
Inoltre puoi personalizzarla con una favicon.ico, una pagina di benvenuto personalizzata, emojis particolari o con uno stile che preferisci.
Naturalmente dovresti seguire @grunfink@comam.es per gli aggiornamenti, ma per qualsiasi domanda relativa a questo processo puoi scrivermi attraverso il fediverse a @giacomo@snac.tesio.it.