------------------------
Stato attuale
------------------------
In Osiris ogni portale è costituito da oggetti. Qualsiasi cosa: topic, post, utenti, avatar, reputazioni.
Attualmente (0.13), TUTTI gli oggetti vengono replicati su ogni nodo (pc).
Poi, esiste il motore di stabilizzazione, che si occupa di valutare quali oggetti visualizzare, conteggiare nelle statistiche, etc.
Anche durante l'allineamento tutti gli oggetti vengono distribuiti.
Ora, questa prima implementazione è problematica, basta immaginare un portale in cui uno spammer crea milioni di post: c'è il sistema per far sì che nessuno li vedrebbe, ma tutti continuerebbero a scaricarli, averli sul pc, condividerli.
Attualmente, è possibile essere registrati ad un portale anarchico, ed avere due account di quel portale che hanno una visione completamente diversa del portale stesso, essendo due utenti con reputazioni diverse.
Attualmente, in un monarchico le reputazioni sono calcolate a partire dal monarca, nell'anarchico a partire dall'utente stesso.
Ricordo quindi che, se un utente crea un contenuto e la comunità lo reputa negativamente, in un anarchico l'utente continua a vedere i propri contenuti (dato che verso lui stesso ha ovviamente reputazione positiva).
Questa architettura fà si che un portale possa avere infinite versioni diverse, dato che nell'anarchico ogni utente è un punto di vista potenzialmente diverso di un portale; il che ad esempio è la causa del fatto che non è mai possibile sapere quando si è allineati al 100%.
Dall'altro lato, il monarchico con il suo unico punto di vista (quello del monarca) è troppo restrittivo, in una community normalmente esiste la possibilità di eleggere dei moderatori e far sì che degli utenti siano in primis visibili solo a certi utenti, e poi successivamente visibili agli altri; cosa che attualmente è concettualmente possibile con gli anarchici ma non con il monarchico.
Oltretutto, la scelta tra un portale monarchico e uno anarchico è un'ostacolo obiettivamente complicato da valutare per chi vuol cimentarsi a creare un portale con Osiris. Oltre a complicarci la vita nel gestire questa distinzione.
------------------------
Il cambiamento radicale
------------------------
Il fatto che Osiris debba gestire "infiniti" punti di vista ci ha creato ostacoli difficilmente sormontabili, o che comunque ci obbliga a valutare soluzioni complesse; come decidere quali oggetti debbano essere cancellati fisicamente, quali possono girare via p2p, come evitare che girino all'infinito (evitar che oggetti piallati ritornino), etc.
Abbiamo pensato a una soluzione fondamentalmente semplice, che cambia radicalmente una logica di funzionamento ma che -potenzialmente- risolve di conseguenza tutti gli altri argomenti spinosi che mancano nel "core" di Osiris per far sì che possa essere considerato "completo" (versione 1.0). Scopo di questa analisi è appunto illustrarvi la teoria, in modo da pianificare perfettamente come implementare le soluzioni ai problemi aperti attualmente.
Il concetto base è l'unificazione tra portali monarchici e portali anarchici, in pratica l'abolizione di questa distinzione.
Non è concepibile l'abolizione delle logiche "anarchiche" di Osiris, altrimenti non sarebbe più "indistruttibile" un portale Osiris.
E il concetto di "monarchico" visto come proprietà di un portale è a nostro avviso precario, in quanto (soprattutto quando rilascieremo i sorgenti) chiunque può creare copie di tali contenuti per inserirli in altri portali, anche se si tratterebbe di copia (e non degli oggetti originali dell'utente originale).
L'idea è che in un portale Osiris ogni utente possa definire chi è "il monarca", ma deve scegliere uno e un solo utente. Potrà scegliere se stesso se vuole.
Il portale si vede in base alle reputazioni del monarca scelto, non in base alle proprie come avviene attualmente nell'anarchico.
Tutti gli utenti che han scelto quel monarca, vedono tutti la stessa visione del portale.
Gli utenti reputati male, non solo non si vedono, ma vengono cancellati fisicamente. Di conseguenza, è come se andassero in "dead-share" (0 fonti, smettono di esistere). Questo evita che un oggetto spam giri all'infinito tra i nodi.
Il monarca definisce anche regole che nessun utente che lo ha scelto può variare, ad esempio:
- regole di sopravvivenza
- filtri per decretare automaticamente utenti o contenuti da reputare negativamente (ad esempio parole usate, link esterni usati, etc.).
- se accettare o meno utenti sprovvisti di una convalida digitale (l'ipotesi di realizzare un "bollino di umanità" attraverso un captcha via Isis).
- impostazioni delle soglie di reputazione (solo positivi, non negativi etc.)
- caratteristiche della board. Ad esempio il nome, la dimensione massima di un oggetto (che attualmente è fissa a 128kb), se cancellare fisicamente le vecchie revisioni di un oggetto e tenere solo l'ultima, o se funzionare da archivio storico completo (come la 0.13 attuale).
Tutte queste caratteristiche saranno gestibili da una pagina, denominata ACP (Admin Control Panel).
Quando qualcuno si registrerà ad un portale Osiris, non sarà più univoco l'ID del portale, ma anche il monarca scelto, di seguito chiamato POV.
Quindi non si sarà più registrati ad un portale con dentro diversi punti di vista, ma si sarà registrati distintamente ai diversi POV.
Provo a spiegare con un esempio pratico questa parte.
Ora come ora molti di voi son registrati alla Ciurma (monarchico) e a Serverless-News (anarchico). Quasi tutti gli utenti son entrati in Serverless News creando una reputazione positiva verso l'utente "Clodo", dato che entrate dal link di invito pubblicato qui.
Nella nuova visione, non sarete semplicemente registrati a "Ciurma" e "Serverless-News",
ma sarete registrati a "Ciurma - Admin" e "Serverless-News - Clodo".
Se un utente Pippo volesse creare uno "spin-off", una versione diversa di un portale, potrà ad esempio
sottoscriversi ad un "Serverless-News - Pippo" da lui creato, in cui in pratica si considera lui stesso il monarca, e ridefinire le regole sopra-citate.
A questo punto, sta a lui farsi conoscere diffondendo link di invito alla sua versione.
Chiunque potrà essere registrato ad entrambi (Clodo e Pippo), che compariranno paralleli (l'home page attualmente mostra i portali registrati, in futuro mostrerà invece i POV registrati).
Due POV riferiti allo stesso portale saranno completamente distinti, sia come file di database, sia come rete di nodi p2p.
Il fatto che si siano formate due reti distinte di nodi, permette sia di cancellare lo spam fisicamente, sia di ottimizzare che tutti i contenuti che girano in una rete siano accettati da tutti, sia il sapere quando si è allineati rispetto agli altri (dato che, ricordo, tutti vedrebbero gli stessi contenuti).
Quando Pippo crea il suo POV, il suo pc sarà di fatto l'unico ad essere fonte (seed) p2p, sta a lui farsi conoscere come se avesse creato un portale nuovo, e convincere altri a sottoscriversi per diventar delle fonti di quel suo POV.
Un esempio particolare:
Io potrei creare un POV diverso di Serverless News, registrando un utente ad-hoc chiamato "Storico".
L'utente "Storico" ha le stesse impostazioni di ACP dell'utente Clodo, ma con la differenza che ha specificato che tutte le revisioni degli oggetti non devono essere cancellate fisicamente e devono girare via p2p.
A questo punto io personalmente sarei sottoscritto a due POV distinti, "Clodo" e "Storico", la maggior parte dell'utenza sottoscritta a "Clodo" (ottimizzato, senza storico), e chi vuole (inizialmente solo il mio pc) tiene comunque in vita l'intero storico del portale.
Allo stesso modo, si potrebbe potenzialmente creare dei POV distinti di sezioni specifiche.
Questo cambiamento mantiene le promesse di indistruttibilità di un portale Osiris, dato che chiunque può creare un POV. Chi lo fà, non può certo pretendere che gli altri veicolino la sua versione (come avviene attualmente).
Se uno spammer è registrato ad un POV, crea spam, e vien reputato negativamente dal monarca o il suo staff, allora i contenuti dello spam vengono cancellati fisicamente ANCHE sulla sua macchina. Se vuole che persistano, può creare il suo POV, ma inizialmente solo lui sarà fonte.
(in seguito, si potrebbe comunque creare un sistema per cui una installazione Osiris inoltra indistintamente, basterebbe fare che si registra automaticamente a qualsiasi POV si annuncia in una rete DHT/Kadmilia).
Il fatto che un nodo p2p dialoghi solamente con gli altri che hanno lo stesso POV, permette:
- Di "lottizzare" blocchi di oggetti, come proposto anche da skynetman qui, il che permetterebbe:
- Di sapere a priori se un nodo è già allineato con un'altro, senza scambiarsi oggetti a caso. Limiterebbe l'uso di banda e CPU da infinito a finito. Ricordo che ora come ora Osiris tenta continuamente di allinearsi, non si mette mai in semplice attesa.
- Di sapere quando l'allineamento è terminato, salvando informazioni sui lotti a livello di Isis (o Kad in futuro). Potenzialmente, anche di sapere un "sono allineato al 90%", calcolato rispetto a quanti sullo stesso Isis sono disallineati rispetto a me.
- Di sapere a priori se un nodo è già allineato con un'altro, senza scambiarsi oggetti a caso. Limiterebbe l'uso di banda e CPU da infinito a finito. Ricordo che ora come ora Osiris tenta continuamente di allinearsi, non si mette mai in semplice attesa.
- Di evitare che un oggetto arrivi, venga cancellato in base alle regole di sopravvivenza, e successivamente mi arrivi di nuovo. Perchè, se l'ho cancellato io, lo cancellano per forza anche gli utenti con cui dialogo.
- Catalizza e incita l'uso di 1 o pochi POV diversi, per potersi allineare con più fonti. Il che porta anche a meno confusione nel consultare i portali.
- Di isolare (portare in dead-share) i contenuti di spam. E' inutile creare spam, se chiunque a cui invio il contenuto lo rifiuterà. Lo spammer deve connettersi al network di nodi di un POV in cui non è mal-reputato per essere visto. Se non è visto, non ha alcun scopo che lo crea lo spam, un pò come non ha senso postare spam in un forum con moderazione preventiva.
Da notare che, se di un portale di 1000 utenti, un utente vuol creare un'altro POV per ragionevoli motivi, e 10 utenti lo vogliono seguire condividendo quel nuovo POV, non serve che tutti e 10 si allineino tra loro 10 -E- tra gli altri 990.
Basta che uno solo di loro (chiamiamolo "gateway") si allinei con gli altri 990, e gli altri 9 attingono da lui.
E' considerabile una specie di collo di bottiglia, però:
- Catalizza e incita a non fare POV diversi, ma piuttosto ad appianare le divergenze
- Chiunque di quei 9 può comunque diventare "gateway".
Questa impostazione aprirà la strada a diverse ottimizzazioni. Il fatto che un db contenga solo un punto di vista, e non multipli da gestire, ci permetterà di semplificare gli algoritmi di selezione/analisi della stabilità, nonchè il calcolo delle statistiche. Significa che potremo migliorare notevolmente le performance, al punto di rendere il processo di stabilizzazione istantaneo.
D'altro canto, tener più visioni diverse di un portale con questa impostazione richiederà più spazio disco, ma obiettivamente è una necessità che avrà pochissima utenza.
------------------------
Note varie / Incongruenze che si risolverebbero / Ottimizzaziooni
------------------------
- Il nome e la descrizione di un portale, che attualmente sono nel link di invito (e quindi non più aggiornabili, se non manualmente dai singoli utenti) potrebbero essere tolti dai link di invito, e inseriti nelle opzioni del POV. Così chi gestisce il portale, cambia il nome, e si "riflette" automaticamente a tutti.
- Attualmente è possibile visitare senza crear account un monarchico, ma NON un anarchico. Si potrà invece visitare sempre senza crear account.
- Attualmente in Isis è necessario uno step di configurazione in più (per specificare l'utente del punto di vista), che verrebbe abolito, semplificando la procedura.
- Attualmente in un'anarchico vien creata una reputazione dal link di invito; nel nuovo sistema non è necessario (si evitano quindi oggetti & calcoli rispetto ad ora).
------------------------
Step di implementazione
------------------------
Sicuramente, dobbiamo consolidare e definire in dettaglio i singoli aspetti (ad esempio, l'elenco di opzioni di ACP) in linea teorica, prima di iniziar ad implementare.
Molte delle caratteristiche sopra-citate possiamo implementarle prima ancora di altre, eventualmente attivabili dai beta-tester in maniera sperimentale se rilasciate incomplete.
In generale, contiamo di implementare diverse cose citate senza stravolgere (ad esempio, senza abolire la distinzione tra monarchico e anarchico).
Questo per dire che in linea di massima cercheremo di rilasciare 0.14 , 0.15 etc. implementando sia le richieste che esulano da questi aspetti, sia alcune delle cose citate qui, fino ad arrivare ad un punto in cui faremo una specie di "fork", una versione destinata a diventare la 1.0, su cui (con l'aiuto dei beta-tester) simulare/testare, mentre la serie dei 0.* continuerà principalmente come bug-fixing.














