Last week, Retric, a member of the CKB community, introduced the Nostr Binding Protocol.
The Nostr Binding Protocol creates a one-to-one mapping relationship between Nostr Events and CKB Cells. Ordinary users can use this protocol to create and distribute native assets on the Nostr social network. These assets on Nostr can also be controlled by Bitcoin addresses through RGB++. In addition, client developers can build products on this protocol. Unlike ETH dApps, which consist of two systems (one off-chain server and one on-chain smart contract), the Nostr Binding Protocol brings a new development paradigm to dApps. It uses a consistent system with different data levels to construct dApps. It is worth noting that the Nostr Binding Protocol can be seamlessly integrated into the CKB Lightning Network in the future to solve the issue of native payments in social networks.
Nostr is a simple, public-private key-based information transmission protocol that aims to create a censorship-resistant global social network. Nostr uses Relays to store and transmit social data (such as posts) to users, and the software that users run is called Clients.
On March 9th of this year, at the first Bitcoin Singapore conference co-hosted by Nervos Foundation and ABCDE, Retric gave a presentation on the theme of “Nostr Ecosystem Development Status and Issues.” The following is a summary of the content based on Retric’s presentation, which can help everyone better understand the Nostr protocol.
The Nostr protocol is probably the simplest thing discussed at this conference today. Compared to other technologies or protocols mentioned by others, it is the easiest to understand because it is very simple itself. Initially, Nostr wanted to create a “Twitter,” but not controlled by Elon Musk, but a more decentralized Twitter that does not engage in censorship and allows for freedom of speech. It wanted to do this, which is a relatively realistic starting point, so it proposed a decentralized protocol for social networks called Nostr. As it developed, people began to realize that these things could be used to not only create a Twitter-like platform, but also a better internet structure for various applications.
Let me briefly introduce the Nostr protocol. It can actually be summarized in one sentence: it is a data that is signed with a private key and propagated through different Relays to be sent to the Clients. Essentially, it means I sign a piece of data in a fixed format with a private key, send it to some Relays, and then let other users pull this data down from these Relays for reading.
The core of Nostr is a JSON structure with different fields, each representing something. For example, the “pubkey” field represents which public key I used to sign the sent data. The “content” field represents the actual content of the signed data, which can be any string, such as a tweet, a number, or an encrypted item. The protocol does not impose any restrictions on it. There is also a signature, which guarantees that the data indeed came from me.
So, the core of Nostr is that simple. It just represents that I signed a piece of data I wrote myself locally with a certain private key. After this data is sent online, the Nostr network structure is also simple, consisting of two components: Relay and Client.
Relay is a server that anyone can set up. Its role is to run continuously online, listen for people sending the aforementioned data, receive it, store it, and provide it to Clients when requested.
The second part is how the data is propagated, which is a specification for propagation, and there are many details inside. For example, when I send this data to a Relay, do the Relays communicate with each other? After I send it to a Relay, does the Relay keep a complete record of the data and provide it whenever requested? There are indeed such detailed questions. Nostr’s answer is “I don’t care, you figure it out.” This “I don’t care” response may seem strange, but sometimes I think it is a clever strategy. Sometimes, too much control can harm things in the real world or online. Therefore, I find it very interesting that Nostr doesn’t care.
For example, when we use centralized social networks like traditional ones, the centralized servers usually store all your data by default. And whenever you request it, they can provide it. However, because Nostr doesn’t care, what situations can arise? Some Relay operators may want to grow and strengthen their operations, so they want to save all messages. Another case is that I am an enthusiast, and I only want to run a small node that accepts data from users I like. There are also those who are willing to accept your data but may delete it after 30 minutes because their server’s disk space is limited, and they don’t want to keep it for too long.
Therefore, it can evolve into many different roles, and these different roles may have different responsibilities. For example, for those who want to run it as a business, they may become professional service nodes and provide stable and long-term services. There are also enthusiasts who can run something like a local area network. So, it will evolve into these different roles.
A common phenomenon is that most Relay nodes are willing to accept some messages but cannot guarantee long-term storage. This structure actually seems more suitable for some social patterns in our real human society. In real social patterns, for example, when I chat with all of you here today, when I speak, you can hear it and know it, but then you leave the venue. After a few days, some people with poor memory may not remember what I said, but some people buy a recorder at the venue and record every word you say. This means that the message may be preserved indefinitely.
This is actually very similar to what is happening in our real world, and it can happen because Nostr does not specify many details or make many regulations, including whether Relays need to communicate with each other or whether they need to synchronize the messages they have. It doesn’t specify the need, but it doesn’t say you can’t do it either. So, many Relays will pretend to be Clients and request data from other Relays to synchronize all the data. However, it does not impose mandatory requirements for communication. One reason is that if I make this requirement that you must communicate, it will become a huge challenge for Relay operators to save data from all users on the entire network. Only professional service providers may be able to operate, while individual enthusiasts may not. So, these are some considerations behind the creation of this simple protocol.
In summary, I think the Nostr protocol is very simple. Another interesting aspect is that at this particular point in time, when we have Bitcoin and blockchain, there is a desire for a consensus to sit down and use a unified format and protocol to create social networks or other internet products. It appears at an interesting point in time. If you just look at the protocol, you may think it is simple and uninteresting. But if you consider the time and significance behind its creation, you may find it more interesting.
Another point is that due to its structure, a lot of verification actually happens on the Clients. In fact, there is only one verification involved, whether the data you publish is really signed by the public-private key pair you declared. This verification is done because, for example, if I post a tweet and say something I shouldn’t say, this tweet will be sent to a Relay. The Relay will then be responsible for delivering it to others. If the Relay does not perform verification, it can claim that it forged a ridiculous statement and sent it to other users. Because the data I send has a signature, the Client that receives the data can perform a verification and confirm that the signature matches exactly what was said. This way, the Relay cannot deceive others.
So, one verification Nostr does is the verification of the signature. In fact, this signature verification is a way to remove the control from centralized servers, such as those of WeChat, where they have full control and can write anything on their servers, and you have no way to determine if they are deceiving you because all the data and rights are on their servers. But with the simplest verification, we can actually remove the rights from the servers and transfer them to the users who own the accounts. As long as you have a public-private key pair, you can let your friends verify and confirm that it is not someone else impersonating you or saying something inappropriate.
So, how has Nostr developed? Here are some data I found in March. Because it is a distributed network, its data is not easy to collect. The data I obtained is from the nostr.band website. The total number of Nostr users is around 370,000, and the daily active users are around 12,000. The total number of Relays that have appeared and been operated is unknown.This node could have 2000+ users, but in reality, the number of nodes that are consistently online is probably less than 200. This means that there are still relatively few users on the platform.
As a comparison, let’s look at the Bluesky protocol. It was reported last year that they reached 2 million users. The data on the right shows where users who left Twitter went, and Mastodon is at the top. Mastodon is an established protocol, and some users also moved to ost news and BlueSky. Nostr, on the other hand, belongs to a smaller group and has fewer users.
This is a general overview of Nostr’s development. Behind the scenes, there are many things that these numbers cannot capture, such as protocol proposals and contributions from developers. If you click on the links, you can see that there is a lot happening, with many people wanting to contribute to this protocol. Nostr is not just about creating a Twitter-like platform; there are also applications for music, YouTube-like content, and blogging.
In summary, the majority of users on Nostr are developers or makers. They are interested in the protocol itself and want to develop on top of it. The number of regular users is relatively small.
Why hasn’t Nostr’s development been as successful as expected, despite its simplicity and promising vision? I believe there are three main challenges. While creating this presentation, I discovered numerous small issues related to client and product experiences. However, it is difficult to address these issues comprehensively. Therefore, I will focus on three important points.
The first major problem is how to find a user’s content within the Nostr network. The current operation of the Nostr protocol involves signing data locally and sending it to multiple relays. Other users can fetch this data from the relays to read it. However, this model has a drawback. When someone wants to read a message, they need to know which relays store that data. This leads to a user experience problem where people ask their friends, “Hey, which relays are you using? I need to set mine to the same ones so we can share data.” This is an inefficient method.
Several developers have proposed solutions to this problem. For example, there is a proposal called NIP-65, which suggests including information about which relays store the data alongside the data itself. This way, when someone wants to read a friend’s message, they can ask which relays their friend usually publishes their data to. Armed with this information, they can then fetch the data from those relays. This is one approach.
There are two finer-grained modes called Inbox and Outbox. Inbox allows users to define which relays they will fetch messages from. For example, if someone wants to @mention you on Twitter or perform other actions, they can send the message to your Inbox relay. Outbox relays specify the relays where a user’s messages will be published, ensuring that the commonly used relays receive the data.
However, a technical challenge arises regarding how to locate the messages. Some proposed solutions involve downloading as much information as possible from the entire network and calculating the probability of a user’s data appearing on different relays based on evidence mentioned in other users’ messages. These probabilities are then used to fetch data from relays to satisfy users’ requests. Another solution is to let users define the relays they use and create groups so that other users can find them. These are some of the existing improvement proposals.
The second significant challenge is content governance. Content platforms and social networks require a significant amount of effort to maintain the quality of content. For example, nobody wants to stumble upon a video of someone being beheaded while browsing Twitter; this is a terrible user experience. Companies invest heavily in content moderation, using algorithms to match and filter content. However, this area is relatively underdeveloped. One reason is that users are generally resistant to algorithmic control, as they feel platforms like TikTok and YouTube already exert such control. However, the problem is not the use of algorithms; it is the lack of user control over them.
Users want the ability to switch algorithms and not be forced to accept the algorithms imposed by platforms like YouTube or TikTok. They want the option to opt out if they dislike an algorithm. This perspective is gradually gaining acceptance. However, content curation, whether through human moderation or algorithmic techniques, is still lacking. Content governance is a challenge because the Nostr network is collectively formed by its users, and there needs to be a mechanism to determine what content is good or bad, what content users are interested in, and what content they are not interested in.
There are some existing improvement proposals, such as labeling data. Nostr has a specific data type that allows users to label data with attributes or categorize it. However, this application is not widespread because users are reluctant to engage in labor-intensive tasks without incentives. In the early days of the internet, there was a spirit of building together, but now users prefer to be consumers. Some have suggested creating APIs to collect data from various sources and filter or categorize it before delivering it to users. While this solution is feasible, it has a significant drawback. It shifts the focus from Nostr as a protocol for data exchange to relying on a single API provider. This transforms the protocol into another Twitter or WeChat behind the scenes. This solution may be good, but people don’t like it, and they will criticize it.
Another solution is called DVM, which aims to use the Nostr protocol to classify or apply algorithms to data through predefined interfaces. Users specify the data format they want, and the system returns the desired data. However, this approach also has some issues.
Then there is Noscript, which suggests embedding filtering algorithms or other necessary technologies directly into the content stored on relays. Clients can download this code and perform local filtering or recommendations. However, this approach is not well-developed, and it is still in the discussion stage.
The third serious problem is the Product-Market Fit (PMF) challenge. Many Nostr products or developers struggle to find PMF due to intense competition. On one hand, there are centralized products, and on the other hand, there is the Web3 blockchain ecosystem. Nostr lacks some business models and faces the issue of network effects. The fewer people migrate to Nostr, the fewer others will follow. PMF is a significant problem.
The largest Nostr client, Damus, posted a tweet by its developer at the end of last year, stating that 2024 may be the last year for Damus. The developer may run out of money to continue the project. This highlights the need to find sustainable directions for public social network projects.
All these problems can be seen as opportunities. For example, if we can find more integration points with blockchain and develop viable business models through collaborations with blockchain funds, it may solve the funding problem for public network projects.
In conclusion, Nostr provides a new alternative for developing applications. It doesn’t have to be limited to two extremes, blockchain or Twitter-like platforms. There is a middle ground called Nostr that is not based on blockchain but is not exclusive software either. Thank you.
