La settimana scorsa, Retric, membro della comunità CKB, ha proposto il protocollo vincolante Nostr.

Il protocollo di associazione Nostr viene utilizzato per creare una mappatura uno a uno tra eventi Nostr e celle CKB. Gli utenti ordinari possono creare e distribuire risorse native nel social network Nostr in base a questo protocollo. Attraverso RGB++, queste risorse su Nostr possono anche essere controllate da indirizzi Bitcoin. Gli sviluppatori client possono creare prodotti su di esso. A differenza della dApp ETH, che è divisa in due sistemi (uno è un server off-chain e l'altro è un contratto intelligente on-chain), il protocollo di associazione Nostr apporta un nuovo paradigma di sviluppo alla dApp. Crea dApp utilizzando un sistema coerente con diversi livelli di dati. È stato riferito che in futuro il protocollo vincolante Nostr potrà essere perfettamente integrato nella rete CKB Lightning per risolvere i problemi di pagamento nativi nei social network.

Nostr è un protocollo minimalista di trasferimento di informazioni basato su chiavi pubbliche e private, dedicato alla creazione di un social network globale resistente alla censura. Nostr utilizza Relay per archiviare dati social (come i post) e trasmetterli agli utenti, che eseguono software chiamato Clients.

Il 9 marzo di quest'anno, alla prima conferenza Bitcoin Singapore co-organizzata da Nervos Foundation e ABCDE, Retric ha tenuto una condivisione a tema su "Situazione e problemi attuali del nostro sviluppo ecologico"👇

Quello che segue è il contenuto compilato in base alla condivisione di Retric, che può aiutare tutti a comprendere meglio il protocollo Nostr:

Questo protocollo Nostr dovrebbe essere la cosa più semplice dell'incontro di oggi. Rispetto ad alcune tecnologie o protocolli di cui altri parlano, è il più semplice da capire perché è anche molto semplice. Ciò che Nostr voleva fare all'inizio era in realtà un "Twitter", ma questo Twitter non era controllato da Elon Musk, ma un Twitter più decentralizzato che non facesse cose cattive o non facesse nulla di male e bloccasse le persone e avesse una certa libertà di parola . Vuole farlo da un punto di partenza più realistico, cioè vuole realizzare un software del genere. A questo scopo ha proposto un protocollo decentralizzato sui social network chiamato Nostr. Poi, ora, tutti stanno cominciando a capire che queste cose non servono solo per creare Twitter, ma più come una migliore struttura di Internet, su cui possiamo creare varie applicazioni.

Vorrei introdurre brevemente prima il protocollo Nostr. In realtà può essere spiegato in una frase: si tratta di dati, firmati da una chiave privata. Questi dati vengono propagati su diversi relè o ripetitori e quindi inviati al client. Essenzialmente, firmo dati in formato fisso e, dopo aver firmato, li invio ad alcuni ripetitori, quindi permetto ad altri utenti di estrarre questi dati da questi ripetitori attraverso il client per leggerli.

L'elemento centrale di Nostr è una struttura Jason, che avrà diversi campi, ogni campo rappresenta un significato. Ad esempio, pubkey è la chiave pubblica che ho utilizzato per firmare i dati che ho inviato. Ad esempio, ha una colonna di contenuto, che significa qual è il contenuto dei dati che ho firmato. Può essere una stringa qualsiasi Ho inviato, oppure può essere un numero o un oggetto crittografato. Non ci sono restrizioni nel protocollo. Anche qui ci sarà una firma, il che significa che ho garantito per i dati che ho inviato, assicurandomi che i dati sono stati effettivamente inviati da parte mia.

Quindi il nocciolo di Nostr è così semplice. In realtà significa semplicemente che ho utilizzato una determinata chiave privata per firmare un determinato dato che ho scritto localmente. Dopo che questi dati sono stati inviati a Internet, anche la struttura della rete Nostr è molto semplice, con solo due strutture, una chiamata Relay e l'altra chiamata Client.

Relay è un server che tutti possono configurare. La funzione di questo Relay è che è sempre in esecuzione su Internet per monitorare chi mi ha inviato i dati che ho appena menzionato, per poi riceverli e salvarli. Se un cliente mi chiede determinati dati, glieli fornirò nuovamente .

La seconda parte riguarda le modalità di diffusione di questi dati, ovvero una specifica per la diffusione, che in realtà contiene molti dettagli. Ad esempio, se passo questi dati a Relay, comunicano tra loro? Oppure, dopo averlo passato a Relay, Relay salverà i dati completamente per me e poi me li fornirà ogni volta che lo richiedo? In effetti, ci sono tali dettagli. La risposta di Nostr è "Non mi interessa, puoi pensarci tu stesso". In realtà è una reazione un po' strana, ma a volte penso che sia una strategia più intelligente. A volte sembra che, indipendentemente dal fatto che sia nel mondo reale o online, a volte si danneggiano alcune cose prestando troppa attenzione, quindi penso che in realtà sia molto interessante lasciarlo stare.

Ad esempio, lascia che ti faccia un semplice esempio Quando utilizziamo un social network centralizzato tradizionale, il server centralizzato salverà tutti i tuoi dati per impostazione predefinita. Poi quando mi chiedi qualcosa, posso dartelo in qualsiasi momento, ma poiché a Nostr non importa, cosa succederà qui? Alcuni operatori Relay vogliono diventare più grandi e più forti e vogliono salvare tutti i messaggi. Questo è un tipo. Un altro modo è che io sono un hobbista, voglio solo costruire un nodo molto piccolo e accetto solo i dati degli utenti che mi piacciono. Ci sono anche alcuni dati che sono disposto ad accettare da te, ma potrei non volerli 30 minuti dopo averli ricevuti e voglio eliminarli perché il disco sul mio server potrebbe essere limitato e non sono disposto a salvarli per questo lungo.

Quindi in realtà si evolverà in molti ruoli diversi, e questi diversi ruoli potrebbero avere diverse divisioni del lavoro. Ad esempio, se qualcuno vuole davvero gestirlo come un'impresa, diventerò un nodo di servizi professionali e farò del mio meglio per fornire a tutti un servizio più stabile e a lungo termine. Ci sono anche alcuni entusiasti che possono anche gestire cose come la LAN, quindi si evolverà in diverse divisioni del lavoro.

Un fenomeno comune è che la maggior parte dei nodi Relay è disposta a ricevere alcuni dei tuoi messaggi, ma non può garantire che verranno salvati per un lungo periodo. Questa struttura in realtà sembra essere più adatta ad alcuni modelli sociali nella nostra società umana reale. Un vero modello sociale. Ad esempio, se sto chiacchierando con tutti qui oggi, potete sentirmi quando parlo, e ve ne accorgerete, e poi lascerete la sala. Dopo due giorni, alcune persone hanno scarsa memoria e non ricordano più di cosa sto parlando, ma alcune persone acquistano un registratore in questo luogo e scrivono ogni parola che dici. Ciò significa che la tua notizia non rimarrà per sempre.

Questo in realtà è molto simile a ciò che sta accadendo nella nostra realtà. Questa cosa può accadere perché Nostr non regola molti dettagli o molte altre cose, e non si preoccupa se Relay debba comunicare o meno con Relay l'uno ha l'altro, ma ciò non dice che non puoi. Pertanto, molti Relay fingeranno di essere un Client e si recheranno anche ad altri Relay per ottenere i propri dati e sincronizzare tutti i dati. Ma non stabilisce requisiti obbligatori, dicendo che devi comunicare. Uno dei motivi è che se faccio questo requisito e tu devi comunicare, ogni relè deve salvare i dati di ogni utente sull'intera rete, nel qual caso sarà un test molto importante per il funzionamento di Relay. Forse solo i fornitori di servizi professionali possono gestirlo e i singoli appassionati potrebbero non gestirlo. Quindi queste sono alcune delle considerazioni alla base della conclusione di questo semplice accordo.

Per riassumere, penso che il protocollo Nostr sia molto semplice. Un'altra cosa interessante è che a questo punto abbiamo Bitcoin e blockchain Ciò che vogliamo avere è un consenso, proprio come ci sediamo tutti e diciamo, oggi usiamo un metodo unificato. In realtà sembra un nodo molto interessante da usare il formato e il protocollo unificato per creare alcuni social network o realizzare alcuni prodotti Internet. Ma ora penso che ci sia una direzione in cui questo nodo possa lavorare sodo, ovvero utilizzare una struttura dati molto semplice e un protocollo di scambio molto semplice per fare alcune delle cose che stanno facendo WeChat, Twitter, ecc. Quindi penso che potresti pensare che sia molto semplice e non interessante a prima vista. Ma se pensi al tempo dietro la sua apparizione, il significato della sua apparizione sarà più interessante.

Un altro punto è che, a causa della sua struttura, un gran numero di verifiche avvengono effettivamente dal lato client. In realtà c'è solo una cosa da verificare qui: se i dati che pubblichi sono effettivamente inviati dalla coppia di chiavi pubblica-privata che hai dichiarato. Viene eseguita solo questa verifica. Perché facciamo questa verifica? Perché ad esempio, se invio un tweet e dico qualcosa che non dovrei dire, questo verrà inviato a Relay. Relay è responsabile dell'invio ad altri. Se Relay non lo verifica, Relay può dire che ho falsificato una frase strana che hai detto e l'ho inviata ad altri utenti. Poiché ho una firma quando invio i dati, il cliente che riceve i dati può fare una verifica e dire che la firma che ha firmato corrisponde esattamente a ciò che ha detto, quindi Relay non può ingannare gli altri.

Quindi una delle sue verifiche è verificare la firma. La verifica di questa firma è in realtà la stessa di quella del nostro Internet centralizzato in passato, come WeChat. Il server su WeChat è controllato da solo e può scrivere qualsiasi cosa su server, non hai modo di essere sicuro che non ti stia mentendo, perché tutti i dati e tutti i diritti sono sul server. Ma finché esiste la verifica più semplice, possiamo effettivamente togliere i diritti al server e consegnarli all'utente che possiede l'account. Finché disponi di una chiave pubblica e privata, puoi chiedere ai tuoi amici di verificarla per assicurarti che nessun altro finga di essere me o dica qualcos'altro di sbagliato.

Allora qual è lo sviluppo di Nostr? Ecco alcuni dati che ho riscontrato a marzo. Poiché si tratta di una rete distribuita, i suoi dati non sono facili da contare. Questi sono i dati che ho ottenuto dal sito web nostr.band. Il numero totale di utenti Nostr potrebbe essere di circa 370.000 e gli utenti attivi giornalieri potrebbero essere solo 12.000. Il numero totale di staffette, le staffette che sono apparse e quante persone hanno attraversato questo nodo potrebbero essere più di 2.000. Ma il numero di questi nodi che sono effettivamente sempre online è probabilmente inferiore a 200. Probabilmente è così, quindi ci sono ancora relativamente pochi utenti.

Per confronto, guarda un confronto con il protocollo BlueSky. Bluesky avrebbe dovuto dire alla fine dell'anno scorso che avevano raggiunto 2 milioni di utenti. I dati a destra sono dove qualcuno ha contato gli utenti che hanno lasciato Twitter e dove sono andati. Puoi anche vedere che Mastodon è al primo posto, e Mastodon è un marchio relativamente vecchio Dopodiché, alcune persone sono andate a ost news, e alcune persone sono andate a BlueSky Nostr appartiene in realtà al quinto livello, che è una parte relativamente piccola.

Questa è una situazione di sviluppo approssimativa. Naturalmente, ci sono molte cose dietro Nostr che non possono essere viste in questo tipo di dati. Ad esempio, alcune proposte sono state presentate al protocollo e gli sviluppatori gli hanno inviato alcune PR. Queste attività o discussioni di sviluppo potrebbero non essere conteggiate, ma se fai clic su questi collegamenti, puoi effettivamente vedere che stanno ancora accadendo molte cose e un gran numero di persone vogliono contribuire a questo protocollo. Queste sono alcune delle cose che tutti usano Nostr per fare. Non solo creo davvero un Twitter, ma ci sono anche molte applicazioni legate alla musica, applicazioni di tipo YouTube e applicazioni di tipo blog.

Quindi lasciatemi riassumere, ora riteniamo che la maggior parte degli utenti siano in realtà sviluppatori o produttori. Sono interessati al protocollo stesso e vogliono sviluppare cose su di esso, oppure io sono una persona che vuole fare qualcosa e lavorerò sul tuo protocollo e potrebbero esserci meno utenti ordinari.

Perché Nostr è così semplice? La visione sembra buona, ma lo sviluppo non è molto soddisfacente, penso che sia anche perché mentre stavo scrivendo questo PPT, ho scoperto che in realtà ci sono molti piccoli problemi con innumerevoli dettagli. ad esempio, dal lato client, ci sono alcuni aspetti relativi all'esperienza del prodotto. Ma in realtà è molto difficile spiegare chiaramente questo genere di cose, quindi ho menzionato solo tre punti che ritengo più importanti.

La prima grande domanda è come trovare i contenuti pubblicati da un utente nella rete Nostr, perché come abbiamo detto prima, il funzionamento dell'intero protocollo Nostr è che firmo le cose localmente e poi le invio a innumerevoli Relay. Altri utenti possono prendere i dati che ho inviato da questi relè e leggerli. Questo è un modello. Ma c'è un problema con questo modello, ovvero, dopo che i miei dati sono stati inviati a Relay, quando il mio amico vuole leggere questo messaggio, come fa a sapere su quale Relay si trova il mio messaggio? Deve sapere su quale Relay sono presenti i miei dati? , è andato a leggerlo. Quindi ora un grosso problema dell'esperienza utente è che quando usano Nostr, molte persone chiedono ai loro amici: "Ehi, quale Relay stai usando? Voglio configurare il tuo stesso Relay in modo che possiamo scambiare questi dati insieme." "Questo è un metodo molto stupido.

Naturalmente, molti sviluppatori hanno presentato alcune soluzioni dettagliate. Ad esempio, esiste una proposta NIP-65, che significa più o meno su quali relè inserirò i miei dati. Inserisco anche queste informazioni sui relè. Quindi diffondo questo messaggio a tutti i Relay il più possibile, in modo che il mio amico vada prima a Relay e faccia una domanda su dove il mio amico di solito invia i suoi messaggi. Dopo aver ottenuto queste informazioni, è andato ai Relay che pubblico spesso e ha chiesto loro i dati.

È diviso in due modalità relativamente dettagliate, una si chiama Posta in arrivo e l'altra si chiama Posta in uscita. Ad esempio, come Inbox, consente agli utenti di definire da quali relè leggerò alcune notizie su di me. Se vuoi @me su Twitter o fai altre cose, puoi inviare questo messaggio a questo Inbox Relay. L'altro è Outbox Relay, che specifica che invierò alcuni dei miei messaggi a diversi Relay A, B, C e D. Probabilmente significa che invierò prima alcuni dei messaggi Relay che spesso pubblico su Relay.

Ma sorge un problema tecnico, cioè come faccio a sapere dove sono le notizie. Quindi esiste anche questo problema e alcune soluzioni sono che utilizzo alcuni algoritmi per scaricare quante più informazioni possibili dall'intera rete. Quindi, da alcune delle prove nascoste di Relay menzionate in alcuni messaggi inviati da altri, prova a calcolare la probabilità che i dati pubblicati da una persona appaiano su cui Relays. Attraverso questo calcolo della probabilità, prova a trovare qualche relè che richiede dati e poi accertati che altri possano trovare i tuoi dati quando vogliono leggerli. Altri consentono inoltre agli utenti di definire alcuni relè che utilizzeranno, creare alcuni gruppi e consentire ad altri utenti di trovarti tramite questi gruppi. Queste sono alcune soluzioni di miglioramento esistenti.

Anche il secondo problema è più serio, chiamato Content Governance. Che si tratti di prodotti di contenuto o di social network, gran parte dell'energia deve essere dedicata al modo in cui si mantengono i contenuti su questo social network. Ad esempio, non hai assolutamente bisogno di vedere un video di qualcuno che decapita qualcuno mentre scorri su Twitter, giusto? Questa è una brutta esperienza? Aziende come questa faranno molte operazioni dietro di loro e hanno bisogno di molte persone per filtrare i contenuti o utilizzare algoritmi per eseguire alcune corrispondenze dei contenuti. In questa parte, il mercato è relativamente vuoto. Ci sono diverse ragioni per questo. Uno dei motivi è che tutti sono molto ripugnanti agli algoritmi su questa piattaforma. Perché sembra che, sia che si tratti di TikTok o di Youtube, gli algoritmi ci controllino, ma in realtà abbiamo bisogno di algoritmi. Significa solo che ciò di cui abbiamo bisogno è che io possa cambiare l'algoritmo.

Non voglio dire che posso solo accettare l'algoritmo obbligatorio fornitomi da Youtube o TikTok per inviare annunci. Spero di avere molti algoritmi che posso cambiare in qualsiasi momento. Se non mi piace questo algoritmo, ho la possibilità di uscire. Questo punto di vista viene lentamente accettato dal suo design. È solo che in quest’area, sia che comprenda operazioni manuali o alcune operazioni sui contenuti, o alcune cose fatte nella tecnologia algoritmica, queste sono ancora relativamente carenti. Quindi il problema principale in questa parte è che la nostra rete è composta da tutti. Ha bisogno di un meccanismo per decidere quale contenuto è buono, quale contenuto è cattivo, quale contenuto ti interesserà e quale contenuto potrebbe interessarti. Per coloro che non sono interessati, questa è in realtà una questione di governance dei contenuti.

Di seguito sono riportati alcuni piani di miglioramento esistenti che ho elencato, come i primi dati di etichettatura. Esiste un tipo speciale di dati su questo Nostr, che consente agli utenti di contrassegnare a quale tipo di determinati dati appartiene o quali sono i suoi attributi. Basta usare questo tipo di etichettatura per etichettare un dato, ma questo non è molto utilizzato perché è molto semplice e nessuno è disposto a farlo. Nessuno è disposto a fungere da membro sociale e ad aiutarti a svolgere parte di questo duro lavoro. La primissima società di Internet aveva questo tipo di spirito di costruzione. Ora è più probabile che le persone lo utilizzino come consumatori. Naturalmente, alcune persone hanno suggerito che posso creare API. Sono specializzato nella gestione di alcuni servizi. Raccolgo dati da alcune società sull'intera rete, quindi eseguo filtri o classificazioni per ottenere notizie più probabili da inviare agli utenti. Questa soluzione è molto semplice da implementare, ma presenta un grosso problema: continuiamo a tornare indietro dopo averlo fatto. Si trasformerà nel dire che non chiedo dati al protocollo Nostr, ma nel dire invece che cerco appositamente un'API che funzioni particolarmente bene e chiedo dati al server di questa API. Quindi questo tipo di accordo diventerà un altro Twitter o un altro WeChat dietro questa API, quindi questa soluzione è molto buona. Il problema è che alla gente non piace. Se lo fai, tutti ti criticheranno.

Esiste un'altra soluzione chiamata DVM. Ciò che vuole fare è utilizzare il protocollo Nostr per eseguire una classificazione o un algoritmo di questi dati utilizzando l'interfaccia specificata dal protocollo. Il suo significato generale è che tu mi dai dei Satoshi di Lightning Network e poi ti restituirò i dati che desideri. Tu specifichi il formato dei dati, ma ci sono anche alcuni problemi con questo.

L'altro è Noscript, che è un'altra idea. Utilizziamo direttamente questi algoritmi di filtraggio o alcune tecnologie necessarie per la classificazione e utilizziamo direttamente questi codici come contenuto, li inseriamo direttamente su Nostr e lasciamo che Relay li memorizzi. Quindi il client estrae direttamente questi codici ed esegue alcuni filtri locali o fornisce alcuni consigli. Naturalmente, lo sviluppo di tutto questo sarà ancora peggiore, perché ora ci sono solo alcune idee e alcune persone ne stanno discutendo.

Il terzo problema più serio è in realtà un problema imprenditoriale, PMF. Al giorno d'oggi, il gran numero di prodotti o sviluppatori di Nostr non riesce a trovare PMF perché deve affrontare molta concorrenza. Da un lato ci sono i prodotti tradizionali centralizzati e dall’altro potrebbe trattarsi della blockchain Web3. Non fanno nulla senza emettere token, quindi in realtà mancano alcuni modelli di business e devono affrontare anche il problema degli effetti di rete, perché meno persone si spostano qui, il che significa che meno persone continueranno a spostarsi qui. Quindi il PMF è un grosso problema.

Il cliente più grande di Nostr si chiama Damus, non so se lo hai utilizzato. Il suo sviluppatore ha inviato un tweet alla fine dello scorso anno, dicendo che il 2024 potrebbe essere l’ultimo anno di Damus. Perché è quasi senza soldi per continuare a farlo. Se non riesce a farlo entro il 2024, non potrà guadagnare nulla. Si tratta quindi anche di trovare una direzione di sviluppo sostenibile per i beni pubblici delle reti sociali.

In effetti, penso che tutti i problemi qui siano anche opportunità. Ad esempio, come l’ultimo PMF, penso che se potessimo avere più posti in cui integrarci con la blockchain, avere modelli di business più fattibili e fare una certa integrazione con i fondi blockchain, potremmo essere in grado di risolvere questo problema. Un problema di finanziamento per i beni pubblici .

Infine, penso che Nostr sia una nuova soluzione per lo sviluppo di applicazioni alternative. Se vuoi realizzare prodotti alternativi, potrebbero non esserci solo due estremi, un estremo si chiama blockchain e l’altro si chiama Twitter. Non è l’unico, potrebbe esserci una via di mezzo chiamata Nostr, che non è basata sulla blockchain, ma non è nemmeno un software proprietario. Grazie.