Nostr has gotten a lot of attention and steam behind it since its recent addition to the list of alternative social platforms whose promotion is prohibited on Twitter. And it’s also gaining ground as it becomes clear that Elon Musk’s purchase of Twitter hasn’t fundamentally changed anything about free speech on the platform: users are it’s still forbidden for inconsistent and arbitrary reasons, and people are looking for a decentralized alternative that isn’t something like Mastodon, where a server operator you still have the ability to control your identity.
Despite recent attention, the developer created the Nostr protocol and the first relay server implementation in late 2020. 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. In both systems, your identity/username is simply something controlled by whoever runs the server. The fact that Mastodon is a federated system with multiple different servers talking to each other does not fundamentally change that reality. Whichever server you use to host an account you are in full control of whether or not you can use it. Even running their own server, other server operators can whitelist or blacklist which servers will be able to communicate with theirs. This has led to a large number of partitions in the “Fediverse” of different Mastodon servers and makes the idea of simply running your own server meaningless. Ultimately, you can still get censored by other server operators, preventing your users from seeing your content in their feed.
The main differentiator between Nostr and something like Mastodon is that instead of using a username owned by a server operator, each user uses a public/private key pair to handle that function. That’s something a server operator can’t just take away or block you from. This is one of the basic components on which the overall Nostr protocol is built.
Next is “events”. This is the basic object/data type used by clients and the relay servers to which the clients connect to send and retrieve 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 communicate with relay servers to request the events they have received and stored. in the original NIBP 01Three different types of events are defined:
- 0 – Sends metadata about a user, such as username, image, bio, etc.
- 1: Send text messages and basic content
- 2: Recommend relay servers for people following the event creator to connect
All events are structured in a specifically defined way. They include the creator’s public key, a timestamp of when they were created, their type (or type in the specification), the content payload, and a 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 a TXID for Bitcoin transactions). This allows you to guarantee that the owner of the public key within it actually created a message when verifying the signature (and the person who owns that key if it is not compromised), and to guarantee that the message was not modified after they signed it. that you can’t alter a Bitcoin transaction after it’s been signed without voiding it, you can’t alter a Nostr event after it’s been signed by the creator without blatant fraud.
The event type system was expanded substantially from that original PIN. There is an event type for encrypted direct messages, which establishes a shared key by combining the sender’s private key with the receiver’s public key, resulting in the same key that you would get by combining the sender’s public key with the private key of the receiver (this is how GDP 47 and Silent Payments work). There are also types for replaceable events and ephemeral events. In the case of a replaceable event (obviously), they’re designed so that the original creator of the event can sign a new one to replace the old one. Relay servers that follow the specification will automatically remove the old event from their storage and begin serving newer versions to clients once they are received. Ephemeral events are designed to be broadcast to anyone who subscribes to their creator when they are sent to the relay, but the relay servers are not supposed to store them. This creates the possibility that the messages will be seen only by people when they are online during their transmission. There’s even an event type to indicate a reaction (like likes or emojis) to other people’s events.
Speaking of the latter, 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 functions, such as email subjects). All of these can include pointers to specific relay servers from which data can be obtained so that users can interact between servers, i.e. a user posting their content to a 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 consistently get the entire thread of interactions in the correct order and without a lot of complexity figuring out where to find the relevant data.
Within the original PIN, a specification is provided for how clients should interact with relay servers through a subscription data/message structure that includes filters for events the client is interested in receiving. Those filters can specify users’ public keys, exact events, event types, and even specific time periods in which they want them based on the above criteria. You can even send public key prefixes or event IDs, like “1xjisj…”. and receive any event(s) from a public key beginning with that short string (this can be useful for hiding from a relay server what you actually want to see).
Overall, the protocol is a very basic generalized scheme for passing messages between users that covers the important stuff like ensuring the integrity of the messages and who sent them with the use of public key identities, while also facilitating infrastructure in the back-end 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 mass chaos in the event a user is kicked off a server relay. They can move to another or run their own and their removal from the old server platform doesn’t cause them to lose their digital identity or followers because they still maintain control over their private key and users can authenticate that when they find them elsewhere.
Relay servers can also operate however they want. They can operate for free, they can charge micropayments to post or download messages, and there are even a PIN for requiring a hashcash-style proof of work to send a message. They can be a single relay server to host and deliver only your posts to other users, or they can be a server running at scale, like Twitter or Reddit (clients can display and organize the information however they want, allowing you to emulate essentially any social network). media platform that exists today). All of these can seamlessly interoperate without being able to exclude a user. You can prevent them from posting content to your relay server, but ultimately you can’t prevent them from seeing the content you host on your relay server or prevent other users from finding your content on other servers.
It’s a very simple protocol with a lot of open design space for people to build into, ensuring that users can always interact with each other, regardless of which individual relay server operators choose to host or not. This is both its greatest strength and its greatest weakness. While it does grant the freedom for developers to build without strict restrictions by a complicated protocol, there are also many problems you will inherently run into that are not handled by the protocol itself.
In the next article I write, I’ll address some of the issues I see occurring and possible solutions, but for now, I’ll just say that in terms of the simplicity of the design and the possibilities it opens up for people to build, Nostr has done a very nice job, considering this is the creation of one person and only a handful of people have actually contributed to the protocol specification so far.
This is a Shinobi guest post. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
