Nostr je privukao veliku pažnju i pažnju nakon što je nedavno dodan na popis alternativnih društvenih platformi čije je promoviranje na Twitteru zabranjeno. Također dobiva na snazi jer je postalo jasno da kupnja Twittera od strane Elona Muska nije bitno promijenila ništa u vezi sa slobodom izražavanja na platformi — korisnicima se i dalje zabranjuje iz nekonzistentnih i proizvoljnih razloga, a ljudi traže decentraliziranu alternativu koja nije nešto poput Mastodona, gdje operater poslužitelja još uvijek ima mogućnost kontrolirati vaš identitet.
Unatoč nedavnoj pažnji, protokol Nostr i implementacija prvog relejnog poslužitelja zapravo su stvoreni krajem 2020. od strane programera fiatjaf. Prije velikog naleta pozornosti, to je bio samo tihi, nišni protokol koji je jednostavno pokušavao biti lagano rješenje za probleme Twittera i Mastodona. Na oba sustava, vaš identitet/korisničko ime jednostavno je stvar koju kontrolira onaj tko pokreće poslužitelj. Budući da je Mastodon federalni sustav s više različitih poslužitelja koji međusobno komuniciraju, to bitno ne mijenja tu stvarnost. Čiji god poslužitelj koristite za hosting računa ima potpunu kontrolu nad time možete li ga koristiti ili ne. Čak i kada pokrećete vlastiti poslužitelj, drugi operateri poslužitelja mogu staviti na crnu ili bijelu listu koji će poslužitelji moći razgovarati s njihovima. To je dovelo do velikog broja particija u “Fediverse” različitih Mastodon poslužitelja i čini ideju da samo pokrenete svoj vlastiti besmislenom. U konačnici vas još uvijek mogu cenzurirati drugi operateri poslužitelja, sprječavajući njihove korisnike da ikada vide vaš sadržaj u svom feedu.
Glavna razlika između Nostr-a i nečega poput Mastodona je ta da, umjesto korištenja korisničkog imena u vlasništvu poslužiteljskog operatera, svaki korisnik koristi javni/privatni par ključeva za rukovanje tom funkcijom. To je nešto što vam poslužiteljski operater ne može jednostavno oduzeti ili vas zaključati. Ovo je jedan od temeljnih blokova na kojima je izgrađen cjelokupni Nostr protokol.
Sljedeći su “događaji”. Ovo je osnovni tip objekta/podatka koji koriste klijenti i relejni poslužitelji na koje se klijenti povezuju kako bi slali i dohvaćali poruke. Opća ideja protokola je da klijenti šalju događaje relejnim poslužiteljima, koji ih zatim pohranjuju i indeksiraju, a drugi klijenti mogu komunicirati s relejnim poslužiteljima kako bi zatražili događaje koje su primili i pohranili. U izvornom NIP-u 01 definirane su tri različite vrste događaja:
- 0: šalje metapodatke o korisniku, kao što su korisničko ime, slika, biografija itd.
- 1: Šalje tekstualne poruke i osnovni sadržaj
- 2: preporučuje relejne poslužitelje na koje se mogu povezati ljudi koji slijede kreatora događaja
Svi događaji strukturirani su na posebno definiran način. Oni uključuju javni ključ kreatora, vremensku oznaku kada su stvoreni, njihovu vrstu (ili vrstu u specifikaciji), nosivost sadržaja i potpis kreatora događaja. Također mogu imati oznake koje se odnose na druge događaje ili korisnike i imati ID vrijednost koja je hash svega osim potpisa kreatora (slično TXID-u za Bitcoin transakcije). To vam omogućuje da jamčite da je poruku stvarno stvorio vlasnik javnog ključa koji se nalazi unutar nje provjerom potpisa (i osobe koja posjeduje taj ključ ako nije ugrožen) i jamči da poruka nije promijenjena nakon oni su to potpisali. Baš kao što ne možete promijeniti Bitcoin transakciju nakon što je potpisana, a da je ne poništite, ne možete promijeniti Nostr događaj nakon što ga je kreator potpisao, a da to nije očigledna prijevara.
Sustav vrste događaja znatno je proširen u odnosu na izvorni NIP. Postoji vrsta događaja za šifrirane izravne poruke, uspostavljanje dijeljenog ključa kombinacijom privatnog ključa pošiljatelja s javnim ključem primatelja, što rezultira istim ključem koji biste dobili kombiniranjem javnog ključa pošiljatelja s privatnim ključem primatelja (ovako BIP 47 i Silent Payments rade). Postoje i vrste za zamjenjive događaje i prolazne događaje. U slučaju zamjenjivog događaja (očito), oni su dizajnirani tako da izvorni kreator događaja može potpisati novi koji će zamijeniti stari. Relejni poslužitelji koji slijede specifikaciju automatski će ispustiti stariji događaj iz svoje pohrane i početi posluživati novije verzije klijentima po primitku. Efemerni događaji dizajnirani su tako da će biti emitirani svima koji su pretplaćeni na njihovog tvorca kada se pošalju releju, ali relejni poslužitelji ih ne bi trebali pohranjivati. Ovo stvara mogućnost da poruke vide samo ljudi kada su na mreži tijekom emitiranja. Postoji čak i vrsta događaja za signaliziranje reakcije (kao što su lajkovi ili emojiji) na događaje drugih ljudi.
Govoreći o ovom posljednjem, događaji također mogu sadržavati oznake. Trenutačno postoje vrste oznaka za događaje (za referencu točno određenog Nostr događaja), javne ključeve (za označavanje ili referencu drugih korisnika) i subjekte (za oponašanje funkcionalnosti, kao što su predmeti e-pošte). Sve ovo može uključivati pokazivače na određene relejne poslužitelje s kojih se podaci mogu dohvatiti tako da korisnici mogu stvarno komunicirati s više poslužitelja, tj. korisnik koji objavljuje svoj sadržaj na jednom relejnom poslužitelju može komunicirati i referencirati sadržaj koji je stvorio drugi korisnik koji objavljuje na drugačiji relejni poslužitelj na način koji svakom korisniku omogućuje koherentno dohvaćanje cijele niti interakcija pravilnim redoslijedom i bez velike složenosti u pronalaženju gdje pronaći relevantne podatke.
Unutar izvornog NIP-a, dana je specifikacija za način na koji klijenti trebaju komunicirati s relejnim poslužiteljima putem pretplatničke poruke/strukture podataka koja uključuje filtere za događaje koje taj klijent želi primiti. Ti filtri mogu specificirati korisničke javne ključeve, točne događaje, vrste događaja pa čak i određene vremenske okvire u kojima ih žele na temelju prethodnih kriterija. Možete čak poslati prefikse javnih ključeva ili ID-ova događaja, kao što je “1xjisj….” i primite bilo koji događaj ili događaje iz javnog ključa koji počinju tim kratkim nizom (ovo može biti korisno za skrivanje od relejnog poslužitelja onoga što ste zapravo htjeli vidjeti).
Sve u svemu, protokol je vrlo gola, generalizirana shema za prijenos poruka između korisnika koja pokriva važne stvari, kao što je jamčenje integriteta poruka i tko ih je poslao uz upotrebu identiteta javnih ključeva, dok također olakšava infrastrukturu na pozadini za relejni poslužitelji koji mogu biti krajnje centralizirani ili dopustiti korisniku da pokrene vlastiti osobni relejni poslužitelj, a sve to u međusobnoj besprijekornoj interakciji i ne izazivajući veliki kaos u slučaju da je korisniku zabranjen pristup jednom relejnom poslužitelju. Mogu se preseliti na drugi ili pokrenuti vlastiti, a de-platformiranje s prethodnog poslužitelja ne gubi njihov digitalni identitet ili sljedbenike jer i dalje zadržavaju kontrolu nad svojim privatnim ključem i korisnici ga mogu autentificirati kada ih pronađu negdje drugdje.
Relejni poslužitelji također mogu raditi kako god žele. Mogu raditi besplatno, mogu naplaćivati mikroplaćanja za objavljivanje ili preuzimanje poruka, a postoji čak i NIP za traženje dokaza o radu u stilu hashcasha za slanje poruke. Oni mogu biti jedan relejni poslužitelj za hosting i posluživanje samo vaših postova drugim korisnicima ili mogu biti poslužitelj koji radi u velikim razmjerima kao što je Twitter ili Reddit (klijentima je moguće prikazati i organizirati informacije kako god žele, što omogućuje oponašanje praktički bilo koje društvene mreže medijska platforma koja danas postoji). Sve ovo može besprijekorno međusobno funkcionirati i bez mogućnosti isključivanja korisnika. Možete ih spriječiti da objavljuju sadržaj na vašem relejnom poslužitelju, ali u konačnici ih ne možete spriječiti da gledaju sadržaj koji hostirate na svom relejnom poslužitelju ili spriječiti druge korisnike da pronađu njihov sadržaj na drugim poslužiteljima.
To je vrlo jednostavan protokol s velikim, otvorenim prostorom za dizajn koji ljudi mogu izgraditi, jamčeći korisnicima da uvijek mogu komunicirati jedni s drugima bez obzira na to što pojedinačni operateri relejnog poslužitelja odluče hostirati ili ne hostirati. To je istovremeno njegova najveća snaga i najveća slabost. Iako jamči slobodu razvojnim programerima da grade bez strogih ograničenja kompliciranog protokola, također postoje mnogi problemi s kojima će se inherentno susresti, a kojima se ne bavi sam protokol.
U sljedećem tekstu koji ću napisati, ući ću u neke od problema za koje vidim da se pojavljuju i potencijalnih rješenja, ali za sada ću samo reći da u smislu jednostavnosti dizajna i mogućnosti koje on otvara ljudima build, Nostr je napravio jako dobar posao, s obzirom na to da je zamisao jedne osobe i da je samo nekolicina ljudi do sada doprinijela samoj specifikaciji protokola.
Ovo je gostujući post od Shinobija. Izražena mišljenja su u potpunosti njihova vlastita i ne odražavaju nužno ona BTC Inc ili Bitcoin Magazine.
