Nostr has gained a lot of attention and steam since it was recently added to the list of alternative social platforms banned from promoting on Twitter. It’s clear that Elon Musk’s purchase of Twitter hasn’t fundamentally changed anything about freedom of expression on the platform — users are still being banned for inconsistent and arbitrary reasons, and people are looking for a decentralized alternative. it’s not like Mastodon where the server operator still has the ability to control your identity.
Despite the recent attention, the Nostr protocol and the first relay server application were actually created by the fiatjaf developer in late 2020. Before the big explosion of attention, it was just a quiet, niche protocol trying to be a lightweight solution to the problems of Twitter and Mastodon. In both systems, your identity/username is simply something that is managed by the person running the server. Mastodon doesn’t fundamentally change this reality by being a federated system with many different servers talking to each other. Whose server you use to host the account has full control over whether you use it or not. Even running your own server, other server operators can blacklist or whitelist which servers are allowed to talk to theirs. This has led to multiple divisions in the “Fediverse” of different Mastodon servers, making the idea of just running your own pointless. You may still be censored by other server operators, preventing their users from seeing your content in their feeds.
The main difference between Nostr and something like Mastodon is that instead of using a username specific to the server operator, each user uses a public/private keyboard to control this feature. This is something that a server operator cannot simply take away from you or shut you down. This is one of the basic building blocks on which the common Nostr protocol is built.
Next is “events”. This is the main object/data type used by clients and the relay servers that clients connect to to send and receive messages. The general idea of the protocol is that clients send events to relay servers, which in turn store and index them, and other clients can contact the relay servers to request the events they receive and store. In the original NIP 01, three different event types were defined:
- 0: Username, photo, bio, etc. sends metadata about the user as
- 1: Sends text messages and basic content
- 2: Recommends relay servers for people following the event creator to join
All events are structured in a specially defined manner. These include the creator’s public key, the time they were created, their type (or type in the specification), the content payload, and the signature of the event creator. They can also have tags that refer to other events or users, and have an ID value that is a hash of everything except the creator’s signature (similar to the TXID for Bitcoin transactions). By verifying the signature, this guarantees that the message was actually created by the owner of the public key it contains (and the person who owns that key, if the key is not compromised), and you guarantee that the message has not been tampered with since then. they signed. Just like you can’t change a Bitcoin transaction after you sign it without voiding it, you can’t change a Nostr event after it’s been signed by the creator without obvious fraud.
The event type system has been greatly expanded from that original NIP. For encrypted direct messages, there is an event type that combines the sender’s private key with the recipient’s public key to create a shared key, which results in the same key that you would get by combining the sender’s public key with the recipient’s private key (that’s how it is). BIP 47 and Silent Payments work). There are also types for replaceable events and ephemeral events. In the case of a mutable event (obviously), they are designed so that the original creator of the event can sign a new one to replace the old one. Relay servers that conform to the specification will automatically remove the old event from their memory and begin serving newer versions to clients upon receipt. Ephemeral events are configured so that when they are sent to a relay, they are broadcast to anyone who subscribes to their creator, but the relay servers do not have to store them. This makes it possible for messages to be seen by people only when they are online at the time of publication. There’s even an event type for reporting reactions (like likes or emojis) to other people’s events.
Speaking of the latter, events can also have tags. There are currently tag types for events (to refer to a specific Nostr event), public keys (to tag or refer to other users), and topics (to mimic functionality like email threads). All of these may include pointers to specific relay servers where data can be retrieved so that users can actually interact between the servers, i.e. interact with a user who posts their content to a relay server and reference content created by another user. a different relay server that allows any user to access all interactions in a consistent manner without the great complexity of figuring out where to find relevant information.
The original NIP specifies how clients interact with relay servers through a subscription message/data structure that contains filters for events that clients are interested in receiving. These filters can specify public keys, exact events, types of events, and even specific time frames that users want based on previous criteria. You can even provide prefixes of public keys or event identifiers, such as “1xjisj…”. and receive any event or events starting with that short string from the public key (this can be useful for hiding what you really want to see from the relay server).
Overall, the protocol is a very bare-bones, generalized scheme for passing messages between users, including essentials such as guaranteeing the integrity of messages and sending them using public-key identities, while simplifying the back-end infrastructure. relay servers, which can be highly centralized or allow a user to run their own personal relay server, while they all interact seamlessly and won’t cause mass chaos if a user is banned from one relay server. They can switch to another or run themselves, and de-platforming them from a previous server doesn’t lose their digital identity or followers, because they still retain control of their private keys and can verify it when users find them elsewhere.
Relay servers can also run as they wish. They can run for free, charge micro-payments to send or download messages, and even have a NIP that requires hashcash-style proof-of-work to send messages. They can be a single relay server just to post and serve your posts to other users, or they can be a large-scale server like Twitter or Reddit (clients can display and organize information however they want, essentially mimicking any social network. media platform that exists today). All of this can work seamlessly without locking out a user. You can prevent them from sending content to your relay server, but ultimately you cannot prevent them from viewing content you post on your relay server or from finding other users’ content on other servers.
It’s a very simplified protocol with a large, open design space for people to build, and it guarantees that users can always interact with each other, regardless of what hosting the individual relay server operators accept. This is both his greatest strength and his greatest weakness. Although a complex protocol guarantees the freedom of developers to build without tight restrictions, there are also many problems that are not solved by the protocol itself.
I’ll address some of the issues and potential solutions in my next post, but for now I’ll talk about the simplicity of the design and the possibilities it opens up to people. build, Nostr has done a pretty good job considering it’s the product of one person’s brain and only a few people have actually contributed to the protocol specification so far.
This is a guest post by Shinobi. The views expressed are entirely their own and do not necessarily reflect the views of BTC Inc or Bitcoin Magazine.