Current Status and Issues of Nostr Ecosystem Development

Last week, CKB community member Retric proposed the Nostr Binding Protocol.

The Nostr Binding Protocol creates a one-to-one mapping relationship between Nostr Events and CKB Cells. Ordinary users can create and distribute native assets in the Nostr social network based on this protocol, and through RGB++, these assets on Nostr can also be controlled by Bitcoin addresses. Client developers can build products on it; unlike ETH dApps which are divided into two systems (one is off-chain servers, and the other is on-chain smart contracts), the Nostr Binding Protocol brings a new development paradigm for dApps, using a consistent system with different data levels to build dApps. It is reported that the Nostr Binding Protocol can seamlessly integrate into the CKB Lightning Network in the future, solving the native payment issues in social networks.

Nostr is a minimalist information transmission protocol based on public and private keys, aimed at creating a censorship-resistant global social network. Nostr uses Relays to store social data (such as posts) and transmit it to users, with the software that users run referred to as Clients.

On March 9 of this year, at the first Bitcoin Singapore conference co-hosted by the Nervos Foundation and ABCDE, Retric gave a keynote presentation titled “Current Status and Issues of Nostr Ecosystem Development.” The following is a summary of the content based on Retric's presentation, which can help everyone better understand the Nostr protocol.

This Nostr protocol should be the simplest thing in today's meeting. Compared to some technologies or protocols discussed by others, it is the easiest to understand because it is very simple. What Nostr initially wanted to do was actually a "Twitter," but this Twitter is not controlled by Elon Musk; rather, it is a more decentralized Twitter that does not engage in bad practices, does not block others, and allows for some freedom of speech. The realistic starting point for wanting to do this is to create such software, proposing a decentralized protocol for social networks called Nostr. Now, it has developed to a point where people are beginning to realize that these things can not only create a Twitter but also resemble a better internet structure where we can build various applications.

Let me briefly introduce the Nostr protocol; it can actually be summarized in one sentence: This is data signed by a private key, which is propagated across different Relays and sent to the Client. Essentially, I sign a piece of data in a fixed format, send it to some Relays, and then allow other users to pull this data from these Relays through their Clients for reading.

The core of Nostr is a JSON structure with different fields, each representing a specific meaning. For example, the pubkey indicates which public key was used to sign the data being sent, and there is a content field that represents what the content of the signed data is; it can be any string, a tweet I posted, a number, or an encrypted item, with no restrictions on the protocol. There will also be a signature, which guarantees that the data I sent indeed came from me.

So the essence of Nostr is that simple; it represents that I locally signed a piece of data using a specific private key. Once this data is sent online, the Nostr network structure is also very simple, consisting of two structures: one called Relay and the other called Client.

A Relay is a server that anyone can set up. The role of this Relay is to run online continuously, listening for people sending me the data I just mentioned, receiving it, and storing it. If a Client requests certain data, I will provide it.

The second part is how this data propagates, which involves a lot of details. For example, if I send this data to a Relay, do Relays communicate with each other? Or after I send it to a Relay, will the Relay help me keep this data intact, so that whenever I ask for it, it will provide it? There are indeed such detailed issues. The answer from Nostr is "I don't care; you figure it out." This indifference might seem strange, but sometimes I think not caring is a rather clever strategy. Sometimes, whether in the real world or online, excessive control can harm certain things, so I find it very interesting that it doesn't care.

For example, let me give a simple example: when we use traditional centralized social networks, that centralized server will by default store all your data. When you ask me for it, I can provide it at any time. However, because Nostr does not care, what situations can arise? Some Relay operators want to grow strong and want to save all messages; that is one scenario. Another scenario is that I am an enthusiast who only wants to run a small node and only accept data from users I like. There are also some who are willing to accept your data, but after 30 minutes, I might not want it anymore and will delete it because my server's disk space may be limited, and I do not want to keep it for too long.

So it actually evolves into many different roles, and these different roles may have different divisions of labor. For example, those who really want to run it as a business will set up a professional service node to provide stable and long-term services. There are also enthusiasts who can run something like a local area network, so it evolves into different divisions of this kind.

A common phenomenon is that most Relay nodes are willing to receive some of your messages, but they cannot guarantee to keep them for a long time. This structure seems to fit better with some social patterns in our real human society. In real social patterns, for example, when I chat with everyone here today, as soon as I speak, you can hear me, and you know it, and then leave the venue. A few days later, some people with poor memory may not remember what I said, but some people in this venue might buy a recorder and record every word you said, which represents whether this message will be preserved indefinitely.

This is very similar to what happens in reality; this can happen because Nostr does not impose regulations on many details or other matters, including whether Relays need to communicate with each other or synchronize the messages they have; it does not specify that they must, but it does not say you cannot. So many Relays will disguise themselves as Clients, seeking data from other Relays to synchronize all data. However, it does not impose mandatory requirements that you must communicate; its reasoning is that if I make this requirement, then every Relay must save every user's data across the network, which would be a significant challenge for operating Relays. Only professional service providers might be able to operate, while individual enthusiasts might not run them. So these are some considerations behind creating this simple protocol.

In summary, I think the Nostr protocol is very simple. Another interesting aspect is that at this current juncture, with Bitcoin and blockchain, there is a desire for consensus, as if we all sit down and say we want to use a unified format and protocol to create some social networks or internet products; it appears at a very interesting juncture. But now, I think there is a direction to strive for, which is to unify using a very simple data structure and a very simple exchange protocol to do some things that WeChat, Twitter, etc., are doing. So I think the protocol may seem simple at first glance, appearing unremarkable. But if you think about the timing and significance behind its emergence, it becomes more interesting.

Another point is that because this structure has a lot of validation happening on the Client side. Here, the validation is about whether the data you publish is genuinely sent by the public-private key pair you declared. Why do this validation? Because, for example, if I post a tweet saying something inappropriate, this will be sent to the Relay. The Relay is then responsible for sending it to others. If the Relay does not validate, it could falsely claim that I said something outrageous to other users. Since I sign the data when sending it, the Client receiving that data can perform a validation check to confirm that the signature matches what was said, preventing the Relay from deceiving others.

Thus, the validation involves checking the signature, which essentially separates the power from the server, which previously controlled everything in centralized internet platforms like WeChat, where they could write anything on the server, and you had no way to determine if they were deceiving you because all data and rights were on the server. But with the simplest validation, we can actually strip power from the server and hand it over to the user who owns the account. As long as you have a public-private key, you can allow your friends to validate and ensure that no one else is impersonating you or saying something inappropriate.

So how is the development of Nostr going? This is some data I found in March. Because this is a distributed network, its data is not easy to quantify. This data is obtained from the nostr.band website, the total number of Nostr users may be around 370,000, with daily active users around 12,000. The total number of Relays that have appeared is about 2000+. However, the number of these nodes that are consistently online is likely below 200. This is roughly the situation, so the user base is still relatively small.

In comparison, looking at its numbers against the BlueSky protocol, BlueSky reportedly reached 2 million users by the end of last year. The data on the right shows where users who left Twitter went, and you can see that Mastodon ranks first; Mastodon is a relatively established protocol. Some users went to ost news, and some went to BlueSky, while Nostr actually belongs to the fifth tier, which is a smaller portion.

This is roughly the development situation; of course, there are many things behind Nostr that are not visible in this data, such as proposals submitted to the protocol and developers submitting PRs. These development activities or discussions may not be quantifiable, but if you click on these links, you can see that many things are happening, with a large number of people wanting to contribute to this protocol. This is what people are doing with Nostr; it is not just about creating a Twitter; there are also many applications related to music, YouTube-type applications, and blogging applications.

So to summarize, we now feel that most users are actually developers or makers. They are interested in the protocol itself and want to develop things on it, or I am someone who wants to create something; ordinary users may be fewer.

Why is Nostr so simple, and while the vision looks good, its development is not very satisfactory? I think it also faces three problems. While writing this PPT, I found many countless small issues, such as client-side product experience. However, these things are difficult to articulate clearly, so I will highlight three points that I think are more important.

The first major issue is how do you find the content posted by a specific user in the Nostr network? As we mentioned earlier, the operation of the entire Nostr protocol involves signing things locally and sending them to countless Relays. Other users can fetch the data I posted from these Relays to read it. However, this model has a problem: after I send this data to a Relay, how does my friend know where this message is stored? They need to know which Relays have my data before they can read it. So a significant user experience issue is that many people using Nostr will ask their friends, “Hey, which Relays are you using? I need to set the same Relays as you so we can exchange this data.” This is a very clumsy method.

Of course, many developers have proposed detailed solutions by now. For example, there is a proposal called NIP-65, which essentially means that I will also post information about which Relays I will place my data on. Then I will try to propagate this information to all Relays, so my friends will first ask the Relays about where I usually post my messages. After obtaining this information, they can then find the Relays I frequently post on to request this data. This is one method.

It divides into two detailed modes: one called Inbox and the other called Outbox. For example, Inbox allows users to define which Relays they will read messages about themselves from. If you want to @ me on Twitter or do something else, you can send this information to the Inbox Relay. The Outbox Relay indicates that I will send my messages to several Relays like A, B, C, and D, meaning that I will also post information about the Relays I frequently use.

However, a technical challenge arises: how do I know where this message is? So this actually poses a problem, and there are some solutions suggesting that I can download as much information as possible from the entire network using algorithms. Then, from the information posted by others, I can extract hidden evidence of the Relays mentioned to try to calculate the probability of where a person's published data appears. By calculating this probability, I can try to request data from some Relays, allowing others to find your data when they want to read it. There are also solutions that let users define the Relays they will use, creating groups that allow other users to find you; these are some existing improvement solutions.

The second issue is also quite serious, called Content Governance. A significant portion of the effort in content products or social networks is dedicated to maintaining the content on the social network. For example, you certainly do not want to see a video of someone getting beheaded while scrolling through Twitter, right? That would be a terrible experience. Companies behind such platforms do a lot of operations; they need many people to filter this content or use algorithms for content matching. This area is relatively vacant in the market. There are several reasons for this; one reason is that people on this platform are very resistant to algorithms. They feel that whether it is TikTok or YouTube, algorithms control us, but in reality, we do need algorithms; we just need the ability to switch algorithms.

I do not want to be forced to accept the advertising algorithms pushed by YouTube or TikTok; I hope to have many algorithms that I can switch at any time. If I do not like a particular algorithm, I want the option to opt out. This viewpoint is slowly being accepted in design. However, currently, whether it is manual operations on content or algorithmic technologies, these are still quite lacking. So the main problem here is that our network is composed of everyone; it needs a mechanism to determine which content is good, which is bad, which content you might be interested in, and which content you might not be interested in. This is essentially a content governance issue.

Below are some existing improvement solutions I have listed. For example, the first is labeling data. In Nostr, there is a specific type of data that allows users to label certain data regarding its type or attributes. By labeling, users can annotate data, but this application is not widespread because, simply put, no one wants to do this. No one wants to act as your social member to help you with this laborious task. In the early internet society, there was a spirit of construction. Now, people are more likely to act as consumers. Of course, some have proposed that I can create an API. I run some services to collect data from companies across the network, then filter or categorize it to provide users with better messages. This solution is very feasible, but it has a significant problem: as we do this, we end up reverting. It becomes that I do not request data from the Nostr protocol but instead seek data from a well-functioning API, which means that this API's server becomes another Twitter or another WeChat. Therefore, this solution is very good, but the problem is that everyone will criticize you if you pursue it.

Another solution is DVM, which aims to use the Nostr protocol to classify or algorithmically process data through specified interfaces. Its general idea is that you give me some satoshis from the Lightning Network, and I will return the data you want, specifying the data format, but this also has some issues.

Another idea is Noscript, which proposes to directly place the filtering algorithms or classification technologies needed as code on Nostr, allowing Relays to store them. Then the Client can pull this code down and perform some local filtering or recommendations. However, this development has not progressed well because it is still just an idea, and some people are discussing it.

The third and quite serious issue is actually an entrepreneurial issue, PMF. Many products or developers on Nostr cannot find PMF because they face significant competition. On one hand, there are traditional centralized products, and on the other hand, there are Web3 blockchain products. They do not issue tokens or anything, so they actually lack business models and face network effect issues. The fewer people migrate over, the fewer will continue to migrate, so PMF is a significant problem.

The largest client, called Damus, I wonder if anyone has used it. Its developer tweeted at the end of last year that 2024 might be the last year for Damus because he is running out of money to continue. If it does not succeed or make money in 2024, it will be over. So this also raises the question of finding a sustainable direction for public goods in social networks.

In fact, all these problems also represent opportunities. For example, regarding PMF, I believe if we can find more areas to integrate with blockchain and develop more viable business models in conjunction with blockchain funds, it might solve the funding issues for public goods.

Finally, I believe that Nostr is a new solution for developing alternative applications. If you want to create some alternative products, it may not only be two extremes: one extreme is blockchain, and the other extreme is Twitter. There is a middle ground called Nostr, which is not based on blockchain but is also not proprietary software. Thank you.