Bitcoiners are flocking to Nostr. But what makes it different than Twitter?

Nostr has received a lot of attention since it was added to the list of social platforms that are banned from promotion on Twitter. It’s also gaining popularity because it’s becoming clear that Elon Musk’s Twitter buyout has not fundamentally changed anything regarding freedom of expression on the platform. Users are still being banned for inconsistent or arbitrary reasons and people are searching for a decentralized alternative to Mastodon, which allows a server operator to control your identity. Despite all the attention, the Nostr protocol was and the first relay server implementation were created by developer fiatjaf at the end 2020. It was a niche protocol that tried to solve the problems of Twitter, Mastodon, and other social media platforms before the attention. Your identity/username on both systems is controlled by the server administrator. Mastodon is a federated system that has multiple servers talking to each other. This doesn’t change the reality. You have complete control over whether or not you can use the account hosted by the server that you use. Other server operators can black-list or whitelist servers that will be allowed to talk with theirs, even if you run your own server. This has caused a lot more partitioning in the “Fediverse”, which means that it is impossible to run your own server. Other server operators can still censor you, preventing their users ever seeing your content in their feed. Nostr is different from Mastodon in that each user uses a public/private keypair instead of a username that is owned by the server operator. This is something that a server administrator cannot seize or lock you out. This is the foundation of the Nostr protocol. Next is “events”. This is the basic object/datatype that clients use to connect to relay servers to send and retrieve messages. The protocol allows clients to send events to relay servers who store and index them. Other clients can then communicate with relay servers to request events that they have received and stored. The original NIP 01 defines three types of events:0: Sends metadata about the user, such as username and bio.1: Sends basic content and text messages.2: Recommends relay server for people following the event creator to connect. All events are structured in a specific way. They contain the public key of their creator, a timestamp showing when they were created, the type of the event creator, and the content payload. They can also contain tags that refer to other events or users. This allows you to verify that the message was created by the owner (or the person who holds it if compromised) and ensure that it wasn’t altered after it was signed. You can’t alter Bitcoin transactions after they’re signed without voiding them. However, you can’t alter Nostr events after their creator signed them without it being obvious fraud. The event type system has been greatly expanded since the original NIP. An event type is available for encrypted direct messages. This creates a shared key by combining sender’s key with receiver’s key. This results in the same key as you would get if you combined the sender and receiver’s keys (this is how Silent Payments and BIP 47 work). There are also types that can be used to replace events and ephemeral. If the event is replaceable (obviously), it is designed so that the original creator can sign a new one. Relay servers that follow the specification will immediately remove the older event from their storage and start serving the newer versions to clients as soon as they are received. Ephemeral events will be broadcast to all subscribers to their creators when they are sent to the relay server. However, relay servers are not supposed store them. This allows people to see messages only when they are online during broadcast. An event type can be used to indicate a reaction (emojis, likes) to other people’s events. Events can contain tags, which is a reference to the last one. There are three types of tag types currently available: public keys (to tag other users), events (to refer to an exact Nostr event), and subjects (to emulate functionality such as email subject). These can all include pointers to specific relay server addresses from which data can be fetched. This allows users to interact across servers. For example, a user who posts their content to one relay server may interact with or reference content posted by another user to a different relay server. This allows users to retrieve the entire thread of interactions coherently and without having to figure out how to locate the relevant data. The original NIP contains a description of how clients interact with relay servers via a subscription message/data format that includes filters to determine which events the client is interested in receiving. These filters can be used to specify the public keys of users, the types of events they are interested in, and even the timeframes that they would like them to arrive based on their criteria. You can also submit prefixes to public keys or event IDs such as “1xjisj ” and receive any event from a public key beginning with this string. This can be useful in hiding what you really want from relay servers. The protocol is a simple, but effective, way to send messages between users. It also allows for the creation of infrastructure on the backend that allows relay servers to be highly centralized or allow users to manage their own relay servers. Users can interact with each other seamlessly and avoid causing chaos if they are banned from one server. They can move to another server or run their own. Their de-platforming from the previous server does not affect their digital identity or followers. Users can still authenticate them using their private key. Relay servers can be operated however they wish. They can be operated for free, charge micropayments to download or post messages, and even have a NIP that requires hashcash-style proofs of work to submit a message. They can serve as a single relay server to host your posts and send them to other users. Or they can run at a large scale like Reddit or Twitter. Clients can organize and display information however they wish, which allows you to emulate virtually any social media platform. All of these can work seamlessly together and you won’t be able to ban a user. While you can block them from posting content to your relay servers, you cannot stop them from viewing the content you host on your relay servers or allowing other users to find their content on other servers. It is a simple protocol that allows users to interact with each other regardless if relay server operators host it. This is both its greatest strength as well as its greatest weakness. It allows developers to create without being restricted by a complicated protocol. However, there are many problems that it will encounter that are not addressed by the protocol. I will write a piece about some of the issues that I see and possible solutions in the next piece. For now, I will just say that Nostr has done an excellent job considering that it was created by one person and that only a few people have contributed to the protocol specification. This is Shinobi’s guest post. These opinions are not necessarily those of BTC Inc.


Add a Comment

Your email address will not be published. Required fields are marked *