Wat maakt Nostr tot een ander sociaal platform – Bitcoin Magazine



Nostr heeft er veel aandacht en stoom achter gekregen sinds de recente toevoeging aan de lijst met alternatieve sociale platforms die geen reclame mogen maken op Twitter. En het wint ook terrein nu duidelijk is geworden dat de overname van Twitter door Elon Musk niets fundamenteels heeft veranderd aan de vrijheid van meningsuiting op het platform — gebruikers worden nog steeds verbannen om inconsistente en willekeurige redenen, en mensen zoeken naar een gedecentraliseerd alternatief dat is niet zoiets als Mastodon, waar een serveroperator nog steeds de mogelijkheid heeft om uw identiteit te controleren.

Ondanks de recente aandacht werden het Nostr-protocol en de eerste relay-serverimplementatie eind 2020 daadwerkelijk gemaakt door ontwikkelaar fiatjaf. Vóór de grote uitbarsting van aandacht was het gewoon een stil, nicheprotocol dat gewoon probeerde een lichtgewicht oplossing te zijn voor de problemen van Twitter en Mastodon. Op beide systemen is uw identiteit/gebruikersnaam gewoon iets dat wordt beheerd door degene die de server beheert. Omdat Mastodon een gefedereerd systeem is met meerdere verschillende servers die allemaal met elkaar praten, verandert die realiteit niet fundamenteel. De server die u gebruikt om een ​​account te hosten, heeft de volledige controle over of u deze kunt gebruiken of niet. Zelfs als u uw eigen server draait, kunnen andere serveroperators op een zwarte of witte lijst zetten welke servers met die van hen mogen praten. Dit heeft geleid tot veel opdeling in de “Fediverse” van verschillende Mastodon-servers en maakt het idee om gewoon je eigen servers te runnen zinloos. U kunt uiteindelijk nog steeds worden gecensureerd door andere serveroperators, waardoor hun gebruikers uw inhoud nooit in hun feed kunnen zien.

De belangrijkste onderscheidende factor tussen Nostr en iets als Mastodon is dat, in plaats van een gebruikersnaam te gebruiken die eigendom is van een serveroperator, elke gebruiker een openbaar/privé-sleutelpaar gebruikt om die functie af te handelen. Dat is iets dat een serveroperator niet zomaar van je af kan pakken of je buiten kan sluiten. Dit is een van de belangrijkste bouwstenen waarop het algehele Nostr-protocol is gebouwd.

De volgende is “gebeurtenissen”. Dit is het basisobject-/gegevenstype dat wordt gebruikt door clients en de relayservers waarmee clients verbinding maken om berichten te verzenden en op te halen. Het algemene idee van het protocol is dat clients gebeurtenissen naar relayservers sturen, die ze op hun beurt opslaan en indexeren, en dat andere clients kunnen communiceren met relayservers om gebeurtenissen op te vragen die ze hebben ontvangen en opgeslagen. In de oorspronkelijke NIP 01 zijn drie verschillende soorten gebeurtenissen gedefinieerd:

  • 0: Verzendt metadata over een gebruiker, zoals gebruikersnaam, afbeelding, een bio, etc.
  • 1: Verzendt tekstberichten en basisinhoud
  • 2: Beveelt relay-servers aan voor mensen die de maker van het evenement volgen om verbinding mee te maken

Alle evenementen zijn gestructureerd op een specifiek gedefinieerde manier. Ze bevatten de openbare sleutel van de maker, een tijdstempel van wanneer ze zijn gemaakt, hun type (of soort in de specificatie), de content-payload en een handtekening van de maker van het evenement. Ze kunnen ook tags hebben die verwijzen naar andere gebeurtenissen of gebruikers, en een ID-waarde hebben die een hash is van alles behalve de handtekening van de maker (vergelijkbaar met een TXID voor Bitcoin-transacties). Hiermee kunt u garanderen dat een bericht daadwerkelijk is gemaakt door de eigenaar van de openbare sleutel erin door de handtekening te verifiëren (en de persoon die eigenaar is van die sleutel als deze niet is gecompromitteerd), en garandeert u dat het bericht daarna niet is gewijzigd ze hebben het ondertekend. Net zoals je een Bitcoin-transactie niet kunt wijzigen nadat deze is ondertekend zonder deze ongeldig te maken, kun je een Nostr-gebeurtenis niet wijzigen nadat de maker deze heeft ondertekend zonder dat het een duidelijke fraude is.

Het evenementsoortsysteem is behoorlijk uitgebreid ten opzichte van dat oorspronkelijke NIP. Er is een gebeurtenistype voor gecodeerde directe berichten, waarbij een gedeelde sleutel tot stand wordt gebracht door de privésleutel van de afzender te combineren met de openbare sleutel van de ontvanger, wat resulteert in dezelfde sleutel die u zou krijgen door de openbare sleutel van de afzender te combineren met de privésleutel van de ontvanger (zo BIP 47 en stille betalingen werken). Er zijn ook typen voor vervangbare gebeurtenissen en kortstondige gebeurtenissen. In het geval van een vervangbaar evenement (uiteraard) zijn ze zo ontworpen dat de oorspronkelijke maker van het evenement een nieuwe kan ondertekenen om de oude te vervangen. Relayservers die aan de specificatie voldoen, zullen de oudere gebeurtenis automatisch uit hun opslag verwijderen en de nieuwere versies na ontvangst aan klanten aanbieden. Kortstondige gebeurtenissen zijn zo ontworpen dat ze worden uitgezonden naar iedereen die zich abonneert op hun maker wanneer ze naar de relay worden verzonden, maar het is niet de bedoeling dat relay-servers ze opslaan. Dit creëert de mogelijkheid om berichten alleen door mensen te laten zien als ze online zijn tijdens de uitzending. Er is zelfs een gebeurtenistype om een ​​reactie (zoals likes of emoji’s) op de gebeurtenissen van andere mensen te signaleren.

Over dat laatste gesproken, evenementen kunnen ook tags bevatten. Momenteel zijn er tagtypen voor gebeurtenissen (om naar een exacte Nostr-gebeurtenis te verwijzen), openbare sleutels (om andere gebruikers te taggen of ernaar te verwijzen) en onderwerpen (om functionaliteit te emuleren, zoals e-mailonderwerpen). Al deze kunnen verwijzingen bevatten naar specifieke relay-servers waarvan de gegevens kunnen worden opgehaald, zodat gebruikers daadwerkelijk kunnen communiceren tussen servers, dwz een gebruiker die zijn inhoud op de ene relay-server plaatst, kan communiceren met en verwijzen naar inhoud die is gemaakt door een andere gebruiker die post op een andere relayserver op een manier die elke gebruiker in staat stelt om de hele thread van interacties coherent op te halen in de juiste volgorde en zonder enorme complexiteit om uit te zoeken waar de relevante gegevens te vinden zijn.

Binnen de originele NIP wordt een specificatie gegeven voor hoe clients moeten communiceren met relay-servers via een abonnementsbericht/gegevensstructuur die filters bevat voor de gebeurtenissen die de klant wil ontvangen. Die filters kunnen de openbare sleutels van gebruikers, exacte gebeurtenissen, soorten gebeurtenissen en zelfs specifieke tijdsbestekken specificeren waarin ze deze willen hebben op basis van de eerdere criteria. U kunt zelfs voorvoegsels van openbare sleutels of gebeurtenis-ID’s indienen, zoals “1xjisj….” en elke gebeurtenis of gebeurtenissen van een openbare sleutel ontvangen die met die korte tekenreeks beginnen (dit kan handig zijn om voor een relayserver te verbergen wat u eigenlijk wilde zien).

Over het algemeen is het protocol een zeer kaal, algemeen schema voor het doorgeven van berichten tussen gebruikers dat de belangrijke dingen dekt, zoals het garanderen van de integriteit van berichten en wie ze heeft verzonden met behulp van openbare sleutelidentiteiten, terwijl het ook de infrastructuur op de backend faciliteert voor relay-servers die extreem gecentraliseerd kunnen zijn of een gebruiker in staat stellen om zijn eigen persoonlijke relay-server te runnen, terwijl ze allemaal naadloos met elkaar communiceren en geen enorme chaos veroorzaken in het geval dat een gebruiker wordt verbannen van één relay-server. Ze kunnen naar een andere overstappen of hun eigen server gebruiken en hun de-platforming van de vorige server verliest hun digitale identiteit of volgers niet, omdat ze nog steeds de controle behouden over hun privésleutel en gebruikers kunnen dat authenticeren wanneer ze ze ergens anders vinden.

Relay-servers kunnen ook werken zoals ze willen. Ze kunnen gratis werken, kunnen microbetalingen vragen om berichten te posten of te downloaden, en er is zelfs een NIP om een ​​bewijs van werk in hashcash-stijl te vereisen om een ​​bericht in te dienen. Ze kunnen een enkele relaisserver zijn voor het hosten en aanbieden van alleen uw berichten aan andere gebruikers, of ze kunnen een server zijn die op grote schaal wordt uitgevoerd, zoals Twitter of Reddit (clients kunnen informatie weergeven en ordenen zoals ze willen, waardoor in wezen elk sociaal netwerk kan worden geëmuleerd). mediaplatform dat vandaag bestaat). Dit alles kan naadloos samenwerken en zonder een gebruiker te kunnen buitensluiten. U kunt voorkomen dat ze inhoud op uw relay-server plaatsen, maar uiteindelijk kunt u niet voorkomen dat ze inhoud bekijken die u op uw relay-server host, of voorkomen dat andere gebruikers hun inhoud op andere servers vinden.

Het is een zeer simplistisch protocol met een grote, open ontwerpruimte voor mensen om te bouwen, waardoor gebruikers gegarandeerd altijd met elkaar kunnen communiceren, ongeacht wat individuele relay-serveroperators kiezen om te hosten of niet. Dit is tegelijkertijd zijn grootste kracht en grootste zwakte. Hoewel het de vrijheid voor ontwikkelaars garandeert om te bouwen zonder strakke beperkingen door een gecompliceerd protocol, zijn er ook veel problemen waar het inherent tegenaan loopt en die niet door het protocol zelf worden opgelost.

In het volgende stuk dat ik schrijf, zal ik ingaan op enkele van de problemen die ik zie optreden en mogelijke oplossingen, maar voor nu zal ik alleen zeggen dat in termen van de eenvoud van het ontwerp en de mogelijkheden die het opent voor mensen om gebouwd, heeft Nostr uitstekend werk geleverd, gezien het feit dat het het geesteskind is van één persoon en dat slechts een handvol mensen tot nu toe echt hebben bijgedragen aan de protocolspecificatie zelf.

Dit is een gastpost van Shinobi. Geuite meningen zijn volledig van henzelf en komen niet noodzakelijkerwijs overeen met die van BTC Inc of Bitcoin Magazine.

Plaats een reactie