What Makes Nostr A Different Social Platform – Bitcoin Magazine
Nostr has gotten a lot of attention and steam behind it since its recent addition to the list of alternative social platforms that are prohibited from promotion on Twitter. And it’s also gaining traction as it’s become clear that the Twitter buyout by Elon Musk 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 that isn’t something like Mastodon, where a server operator still has the ability to control your identity.
Despite the recent attention, the Nostr protocol and first relay server implementation were actually created at the end of 2020 by developer fiatjaf. Before the big burst of attention, it was just a quiet, niche protocol simply trying to be a lightweight solution to the problems of Twitter and Mastodon. On both systems, your identity/username is simply a thing controlled by whoever is running the server. Mastodon being a federated system with multiple different servers all talking to each other doesn’t fundamentally change that reality. Whoever’s server you use to host an account is in total control of whether you can use it or not. Even running your own server, other server operators can black- or whitelist which servers will be allowed to talk to theirs. This has led to a lot of partitioning in the “Fediverse” of different Mastodon servers and makes the idea of just running your own meaningless. You can still ultimately be censored by other server operators, preventing their users from ever seeing your content in their feed.
The core differentiator between Nostr and something like Mastodon is that, instead of using a username owned by a server operator, each user utilizes a public/private keypair to handle that function instead. That is something that a server operator cannot simply seize from you or lock you out of. This is one of the core building blocks on top of which the overall Nostr protocol is built.
The next is “events.” This is the basic object/data type used by clients and the relay servers that clients connect to in order to send and retrieve messages. The general idea of the protocol is that clients send events to relay servers, who then in turn store and index them, and other clients can communicate with relay servers to request events they have received and stored. In the original NIP 01, three different event types are defined:
- 0: Sends metadata about a user, such as username, picture, a bio, etc.
- 1: Sends text messages and basic content
- 2: Recommends relay servers for people following the event creator to connect to
All events are structured in a specifically-defined way. They include the public key of the creator, a timestamp of when they were created, their type (or kind in the specification), the content payload and a signature from the event creator. They also can have tags referencing other events or users, and have an ID value which is a hash of everything except the creator’s signature (similar to a TXID for Bitcoin transactions). This lets you guarantee that a message was actually created by the owner of the public key inside of it by verifying the signature (and the person who owns that key if it isn’t compromised), and guarantee that the message wasn’t altered after they signed it. Just like you can’t alter a Bitcoin transaction after it’s signed without voiding it, you can’t alter a Nostr event after the creator signed it without it being an obvious fraud.
The event kind system was expanded quite substantially from that original NIP. There is an event type for encrypted direct messages, establishing a shared key by combining the sender’s private key with the receiver’s public key, which results in the same key you would get by combining the sender’s public key with the receiver’s private key (this is how BIP 47 and Silent Payments work). There are also types for replaceable events and ephemeral events. In the case of a replaceable 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 following the specification will automatically drop the older event from their storage and begin serving the newer versions to clients upon receipt. Ephemeral events are designed so that they will be broadcast to anyone subscribing to their creator when sent to the relay, but relay servers are not supposed to store them. This creates the possibility of having messages seen only by people when they are online during its broadcast. There is even an event type to signal a reaction (such as likes or emojis) to other people’s events.
Speaking of that last one, events can also contain tags. Currently there are tag types for events (to reference an exact Nostr event), public keys (to tag or reference other users) and subjects (to emulate functionality, such as email subjects). All of these can include pointers to specific relay servers from which the the data can be fetched so that users can actually interact across servers, i.e., a user posting their content to one relay server can interact with and reference content created by another user posting to a different relay server in a way that allows any user to coherently fetch the entire thread of interactions in the proper order and without massive complexity in figuring out where to find the relevant data.
Inside the original NIP, a specification is given for how clients are to interact with relay servers through a subscription message/data structure that includes filters for what events that client is interested in receiving. Those filters can specify users’ public keys, exact events, types of events and even specific timeframes in which they want them based on the prior criteria. You can even submit prefixes of public keys or event IDs, such as “1xjisj….” and receive any event or events from a public key that begin with that short string (this can be useful for hiding from a relay server what you actually wanted to view).
Overall, the protocol is a very bare bones, generalized scheme for passing messages between users that covers the important things, such as guaranteeing the integrity of messages and who sent them with the use of public key identities, while also facilitating infrastructure on the backend for relay servers that can be extremely centralized or allow a user to run their own personal relay server, all while seamlessly interacting with each other and not causing massive chaos in the event of a user being banned from one relay server. They can move to another one or run their own and their de-platforming from the prior server does not lose them their digital identity or followers because they still maintain control over their private key and users can authenticate that when finding them elsewhere.
Relay servers can operate however they want as well. They can operate for free, can charge micropayments to post or download messages, and there is even a NIP for requiring hashcash-style proof of work to submit a message. They can be a single relay server for hosting and serving only your posts to other users, or they can be a server running at massive scale such as Twitter or Reddit (clients can display and organize information however they want, which allows emulating essentially any social media platform that exists today). All of this can interoperate seamlessly and without being able to shut out a user. You can prevent them from posting content to your relay server, but ultimately you can’t stop them from viewing content you host on your relay server or stop other users from finding their content on other servers.
It is a very simplistic protocol with a large, open design space for people to build, guaranteeing users can always interact with each other regardless of what individual relay server operators choose to host or not host. This is simultaneously its greatest strength and greatest weakness. While it guarantees the freedom for developers to build without tight constraints by a complicated protocol, there are also many problems that it will inherently run into that are not handled by the protocol itself.
In the next piece I write, I will go into some of the issues I see occurring and potential solutions, but for now, I’ll just say that in terms of the simplicity of the design and the possibilities that it opens up for people to build, Nostr has done a very good job, considering it is the brainchild of one person and only a handful of people have really contributed to the protocol specification itself so far.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
