Current Status and Issues of Nostr Ecosystem Development

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

The Nostr Binding Protocol is used to create 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 be seamlessly integrated 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 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 content is organized 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; it is a more decentralized Twitter that does not do bad things, 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 summed up in one sentence: This is data signed by a private key, which is propagated across different Relays and sent to Clients. Essentially, I sign a fixed-format piece of data, 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 meaning. For example, 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 just 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, 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 is propagated, which involves a lot of details. For example, when 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, being overly controlling can harm certain things, so I find it very interesting that it does not impose strict rules.

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 for it, I can provide it at any time. However, because Nostr does not impose such rules, what happens? Some Relay operators want to grow and strengthen, so they want to save all messages. Another type is an enthusiast who only wants to run a small node and only accepts data from users they like. There are also some who are willing to accept your data but may not want it after 30 minutes; they want to delete it because their server's disk space may be limited, and they 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. Enthusiasts can also run something like a local area network, so it will evolve 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 that they will be stored 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 the venue buy a recorder to record every word you say, 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 require this, but it does not say you cannot. Therefore, many Relays will disguise themselves as Clients, seeking data from other Relays to synchronize all data. However, it does not impose a mandatory requirement that you must communicate; its reasoning is that if I make this requirement, then every Relay must save every user's data across the entire network, which would be a significant challenge for operating Relays. Only professional service providers might be able to operate, while individual enthusiasts might not.

In summary, I think the Nostr protocol is very simple. Another interesting aspect is that at this point in time, 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 simple exchange protocol to do things like WeChat and Twitter. 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 involves a lot of validation happening on the Client side. There is actually just one verification: whether the data you publish is genuinely sent by the public-private key pair you declared. Why do this verification? 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 perform verification, it can claim that I fabricated a bizarre statement and sent it to other users. Since I have a signature when sending data, the Client receiving that data can perform a verification to confirm that the signature matches what was said, thus preventing the Relay from deceiving others.

So its verification is the signature check, which essentially separates the power from the server in the past centralized internet, such as WeChat, where the server controls everything. It can write anything on the server, and you cannot determine whether it has deceived you because all data and rights are on the server. But with the simplest verification, we can actually strip the 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 verify and ensure that no one else is impersonating you or saying something inappropriate.

So how is the development of Nostr? 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 is around 370,000, with daily active users possibly around 12,000. The total number of Relays that have appeared is about 2000+. However, the number of these nodes that are continuously online is likely below 200. This is roughly the situation, so the user base is still relatively small.

In comparison, looking at its comparison with the BlueSky protocol, Bluesky claimed to have 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, such as proposals submitted to the protocol and developers submitting PRs. These development activities or discussions may be difficult to quantify, but if you click on these links, you can see that many things are happening, with many people wanting to contribute to this protocol. This is what people are doing with Nostr; it’s not just about creating a Twitter; there are many applications being developed in music, YouTube-like 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, while ordinary users may be fewer.

Why is Nostr so simple, and while the vision seems good, its development is not very satisfactory? I think it also faces three issues. While writing this PPT, I realized there are countless small detail issues, such as client and product experience. However, these things are difficult to explain clearly, so I will highlight three points that I think are important.

The first major issue is how to find where a user's content is located within the Nostr network. As we mentioned earlier, the entire operation of the Nostr protocol involves signing things locally and sending them to countless Relays. Other users can fetch the data I sent from these Relays to read. However, there is a problem with this model: 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 now 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 rather clumsy method.

Of course, many developers have proposed detailed solutions, such as a NIP-65 proposal, which essentially means that I will also place information about which Relays I will put my data on in the Relay. Then I will try to propagate this information to all Relays, so my friend will first ask the Relay a question about where I usually send my messages. After obtaining this information, they can then find the Relays I frequently use 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, such as A, B, C, and D, meaning I will first send the information about the Relays I frequently use to the Relay.

However, a technical challenge arises: how do I know where this message is? So this actually poses a problem, and there are some solutions that involve using algorithms to download as much information as possible from the entire network. Then, based on the hidden evidence of the Relays mentioned in the information sent by others, attempt to calculate the probability of where a person's published data appears across several Relays. By calculating this probability, we can try to find some Relays to request data, allowing others to find your data when they want to read it. Some solutions also allow users to define the Relays they will use and group them, enabling other users to find you through these groups, which are some existing improvement solutions.

The second issue is also quite serious, called Content Governance. A significant part of the effort in content products or social networks is how to maintain the content on this social network. For example, you definitely do not want to see a video of someone being 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 for several reasons. One reason is that people on this platform are very resistant to algorithms. They feel that whether it’s 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 algorithms that YouTube or TikTok uses to push ads; I hope to have many algorithms that I can switch between at any time. If I do not like a particular algorithm, I want the option to opt out. This perspective is slowly being accepted in design. However, currently, whether it involves manual operations or algorithmic techniques for content, there is still a significant shortfall. The main issue here is that our network is composed of everyone, and 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 according to its type or attributes. By labeling, data can be annotated, 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 days of the internet, 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 various companies across the web, then filter or classify it to provide users with better messages. This solution is relatively easy to implement, but it has a significant problem: doing so would mean we are no longer seeking data from the Nostr protocol but instead looking for a well-functioning API, requesting data from that API's server. Thus, the protocol would eventually turn into another Twitter or another WeChat, so this solution is very good, but the problem is that people do not like it; if you pursue this, everyone will criticize you.

Another solution is DVM, which aims to use the Nostr protocol to create a classification or algorithm for data using predefined 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 suggests directly placing the filtering algorithms or classification technologies needed into Nostr as content, allowing Relays to store them. Then, the Client can pull this code down and perform 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 more serious issue is actually a startup issue, PMF. Many products or developers in Nostr are struggling to find PMF because they face significant competition. On one hand, there are traditional centralized products, and on the other, there are Web3 blockchain products. They do not issue tokens or anything, so they lack business models and face the network effect problem. The fewer people migrate over, the fewer will continue to migrate, so PMF is a significant issue.

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 they are running out of money to continue. If they cannot make it work or earn money in 2024, they will have to stop. So this also raises the question of how to find 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, we may solve the financing issues of these public goods.

Finally, I believe 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.