💾 Archived View for gemlog.blue › users › roberto_vpt › 1636567252.gmi captured on 2022-03-01 at 15:25:27. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-04)
-=-=-=-=-=-=-
2021-11-11
Penso che i certificati client siano perfetti per autorizzare ma manca l'autenticazione diretta.
Inoltre la rete potrà aumentare solo se si formeranno gruppi di interesse basati su specifiche capsule.
Prima di impostare una propria capsula bisogna almeno avere qualcosa da scrivere ma si può arrivare a condividere interessi in un gruppo.
Penso ad una capsula gemini-it in cui si possa chattare direttamente con possibilità di iscrizione e gemlog.
Poi nel tempo un user può lanciare una sua capsula e trasferirvisi.
Questo potrebbe essere un progetto italiano se vogliamo.
Vi spiego l'idea.
Roberto Soccoli
Per @user permetterei SOLO alfanumerici più _.
Le maiuscole sono consentite ma i server indicizzano in minuscolo.
Per semplicità da ora chiamo un server capsula.
Il proprietario della capsula che utilizza questo protocollo è il primo iscritto da qui deriva lo pseudo DNS @user => @capsula.
E su questo puoi costruire...
Il servizio sarà distribuito tra le capsule che accettano certificati client ed implementano le specifiche.
Per partire serve almeno una capsula con capacità NickServ pronta a ricevere e registrata nel codice del servizio oppure inserita a mano.
Poi gli aggiornamenti arriveranno e la catena si allungherà.
Un NickServ a differenza di una capsula registra permanentemente gli @user con riferimento alla loro @capsula.
Su ogni capsula viene registrato un servizio /NickServ che redireziona al primo della lista locale, quello con più @users.
Se il NickServ sa di non essere il primo mette un redirect sul primo conosciuto, che la capsula registra come primo e ripete la richiesta.
Quando il NickServ sa di essere il primo della lista chiede l'@user da verificare.
NB È un protocollo tra capsule e comunque un client normale riesce a trovare la capsula con l'@user a bordo partendo da /NickServ.
Se una capsula tiene in un database tutti gli @user@server diventa un NickServ.
Alla fine tutte le capsule si rivolgeranno ai NickServ di vertice, anche se l'ordine non sarà aggiornato.
Compito delle capsule NickServ è aggiornare quella successiva così da restare bilanciate.
Si terrà conto del numero degli @user registrati in modo da mantenere la lista delle capsule ordinata per numero maggiore di @user.
Nelle capsule l'elenco delle altre capsule resta permanente gli user invece sono temporanei.
Una capsula cerca @user già identificati, ottenendo l'identità comleta di @capsula, ed aggiorna/registra le capsule conosciute.
Se @user è già utilizzato con un certificato diverso la capsula lo saprà subito e dovrà chiudere il collegamento con errore.
Altrimenti @user viene riconosciuto e messo nel buffer temporaneo dei verificati.
La teporaneità dipende dalle visite e dopo un certo tempo di assenza i riferimenti all' @user saranno cancellati.
Una capsula può esporre i propri @user registrati su /users.gmi, con in prima riga nr users e data.
Ogni capsula iscrive i nuovi membri sul servizio con @user unico in rete.
Se l'@user è nuovo viene registrato col riferimento alla capsula registrante.
Il NickServ aggiorna il NickServ successivo della lista ricorsivamente.
Le capsule che non sono NickServ cessano di propagare.
Una nuova registrazione con lo stesso certificato cambia il riferimento alla capsula registrato.
Se il servizio è completo di gemlog bello sarebbe il trasferimento della home.
L'@user registrato che si connette non solo avrà un certificato valido ma anche un user conosciuto e verificabile sulla capsula registrata.
Il servizio minimo sarà lasciare messaggi diretti agli @user locali delle capsule visitate.
Per gli @user registrati saranno disponibili specifici servizi CGI.
Se sulla capsula è disponibile ci sarà la chat generale /#.
Indice delle stanze disponibili per /#argomento su /#index.gmi.
Se la capsula ne tiene conto si possono scaricare i log non letti per @user.
NB Eventualmente sul client i soliti #hashtag possono restringere i log scaricati.
Una capsula può esporre i propri @user locali su /members.gmi, con in prima riga nr members e data.
Ogni link su /members.gmi permette di mandare un messaggio al @member.
Il servizio minimo per un @member è una casella di messaggi riservata: /@member/msgbox.
Un @member potrebbe ottenere un gemlog se è disponibile l'upload.
In questo caso ogni link su /members.gmi punta a /@member/index.gmi
Standardizzerei alcune pagine sempre presenti in home :
Ritengo sia necessario in caso di eventuale modifica delle pagine aggiornare la data.
Nulla le pagine descritte sopra sono disponibili in lettura.
Si dovrebbero accettare messaggi anonimi, senza certificato, diretti al proprietario della capsula.
Ovviamente posta e chat restano riservate per gli @user con certificato verificato.
Scusate possibili errori, questa è una bozza buttata di getto con ripensamenti e aggiunte in tempi diversi ma spero di aver scritto in modo comprensibile.
Tutto è basato sul protocollo Gemini tranne l'upload probabilmente.
Ho visto che sono consentiti circa 1000 caratteri, il doppio rispetto Mastodon.
Ma non ho esperienza dell'editing in Gemini e nemmeno delle chat disponibili.
Probabilmente se vorremo proseguire dovremo usare una chat almeno audio.
Grazie dell'attenzione