Nostr is a protocol that I have been following for the past two years. Like all communities, Nostr's development has had its ups and downs, with moments of breaking into the mainstream, as well as quieter times like now that might make one feel a bit stagnant. However, I still keep an eye on Nostr, not for any particular reason, but simply because I like it.
What distinguishes Nostr from other social network protocols? If the Bitcoin community has a P2P economic development model that differs from that of the Ethereum community, what are the characteristics of this model, and how does it lead to essential differences in social network applications compared to products like Ethereum's Farcaster? This is a complex question, and today I want to try to share some thoughts from several perspectives, then combine it with the recent AI Meme craze to discuss the differences represented by Bitcoin + Nostr's Web5 route in this specific application scenario.
Openness#
In my view, Nostr, as the simplest social network protocol — note that I haven't even added the term "decentralized" — has its greatest potential in openness. This year, there was a talk at the Nostr conference titled Openness Is Nostr’s Killer Feature, which speaks to this point.
The openness referred to here not only pertains to whether it is technically feasible, meaning whether the protocol's design architecture allows for functional extensions on its basis, but also includes whether the ecological and governance structure of the protocol itself is open. If you examine it from this perspective, you will find that Nostr is indeed the truly open social network protocol.
Openness in Protocol Design#
First, in terms of protocol design, Nostr's approach is to reach a consensus on a basic, large framework, which is a simple JSON data structure, also called an Event.
{
"id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
"created_at": <unix timestamp in seconds>,
"kind": <integer between 0 and 65535>,
"tags": [
[<arbitrary string>...],
// ...
],
"content": <arbitrary string>,
"sig": <64-bytes lowercase hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
}
We first reach a basic consensus that we all agree on the definitions of each field in this JSON data. Then we agree that all data on the Nostr network is structured as such JSON, meaning all data is an Event. Next, we agree that the activities across the entire Nostr network essentially involve the back-and-forth transmission of Events between clients and data-storing servers (also called relays). This is the entirety of NIP01 (the proposal for the core Nostr protocol). Of course, it should be noted that NIP01 also has a consensus that we agree that when the kind of an Event equals 1, this Event is a data type used to describe short messages similar to Twitter.
In such a very simple protocol design, do we have the openness to extend it? If I want to do something I find interesting on top of it, does the protocol itself support me in doing so? The answer is yes.
I will give a somewhat absurd example: suppose today I suddenly want to record every tree in the world and create a forest app that logs information such as the age, species, location, and growth conditions of trees, allowing users to upload trees they discover and view trees recorded by others. Then I can use Nostr to do this. I just need to find a new number as the value for kind, say 12345 as the tree kind, and then record the information in an Event with kind = tree kind. Everything else can be done within the consensus framework of the large Nostr protocol.
Others can continue to do what they care about, possibly operating as a social network like Twitter, while my app focuses on capturing, displaying, and sending Events related to the tree kind. This Event will coexist harmoniously with other Events in the larger Nostr network. Therefore, in terms of the protocol's openness, the way we achieve extension is very simple: as long as we operate within a large framework, we can make small proposals for our functionalities, establishing new Event types to describe new data by adding new kinds.
Openness in Ecology and Governance#
So what about the openness of the ecological and governance structure of the protocol? Does Nostr have openness? Taking our forest app as an example again, theoretically, the governance of the Nostr protocol only occurs in one place: https://github.com/nostr-protocol/nips. The NIP repository records all the major foundational consensuses we just mentioned, as well as various smaller consensuses proposed by different people, such as our forest app being one of them. If we want the idea of the forest app to be accepted by more people, we can propose a new proposal to the NIP repository, listing the specifications for the Event data used by the forest app, so that others can also adhere to this specification. If the administrators of the NIP repository agree and merge our proposal, it becomes an official sub-specification.
Now, some might think that this means the Nostr protocol is controlled by the administrators, who can merge proposals at will or choose not to. This is true, but there are two points worth noting:
- All proposals for Nostr are publicly discussed on GitHub. This is a free market for ideas. People will openly debate every proposal that is merged. If your idea is flawless and hard to refute, there is no reason to prevent it from being merged.
- The second point, which is more important, is that whether or not a proposal is merged is not that significant.
Because in the ecology, the powers of protocol governance, client developers, and relay operators are decoupled. If a client developer initiates a new NIP proposal but the governance refuses to merge it, it doesn't have much impact; they can continue to serve their users with their client as long as the relay operators accept this new Event, everything will function smoothly. If the relay operators also disagree with this new Event and resist accepting this data type, assuming the forest app is indeed a good idea with many users, those users will shift their demands to find relay nodes that support this Event. Ultimately, even if all relays resist this new Event, the forest app can operate its own dedicated relay, thus solving the problem. When the number of users is sufficient and this new Event is active enough in the network, other ecological roles will naturally have to consider integrating this Event.
Conversely, the same applies to relays. There is a sense of carrying users to command the lords. The fundamental reason is that the client and relay ecological roles are interchangeable; clients can replace relays, and relays can replace clients, meaning no user is bound to any single link, allowing them to make the best choices for themselves. Users will vote on these choices, using factual standards to retroactively push the theoretical standards of the NIP repository. This is also a way that is closer to rough consensus and running code. Therefore, I believe that in terms of the ecological and governance structure of the protocol, Nostr also possesses valuable openness.
Moreover, you will find that this openness is somewhat similar to Bitcoin's governance model. Bitcoin's POW allows governance to achieve a separation of powers, with code developers, miners running nodes, and coin-holding users forming a system of checks and balances. The NIP repository of Nostr is like the Bitcoin C++ code repository, needing to consider whether node operators will adopt your new code or new standards; if no nodes adopt it, then the rules on paper do not hold much significance.
Verifiability#
The second point that attracts me to Nostr is verifiability. A common saying in our industry is "Don't trust, verify." In fact, many systems can be verified; the key difference lies in the cost of verification. For instance, in terms of a currency system, Bitcoin's verification is straightforward; you only need to check whether the block hash meets the POW difficulty, while Ethereum's POS is much more complex, requiring you to verify the signatures of all staking nodes and their voting processes, among other things. On the other hand, the UTXO model significantly lowers the threshold for verifying a transaction; you only need to focus on the transaction's input and output, whereas in Ethereum's account model, you need to compute the world state, as every transaction could potentially rewrite the state.
For Nostr, the cost of verification is also very low. Events, as Nostr's data, are decentralized and independent. Anyone in the network who has doubts about a piece of data can simply take this Event and calculate whether the event id and signature are correct according to the rules. Nostr does not require a chain-like data signature like Scuttlebutt, nor does it have two systems like Farcaster's social-fi, where you need to verify both systems simultaneously. The verification cost for Ethereum, as we mentioned earlier, is indeed quite challenging.
Nostr's lightweight verification cost stems from its very simple design, essentially because Nostr has done a lot of subtraction. Nostr only provides a very thin layer of trust, which is that you can trust a certain Event data indeed comes from a specific user (a specific pair of public and private keys) because you can verify the signature.
Beyond that, Nostr does not provide any other guarantees, such as data availability (relays may discard your Event at any time), data ordering (you cannot confirm that the first Event received is the first one created, while Scuttlebutt can achieve this through chain-like data signatures), or DID identity (Nostr's ID is just a pair of public and private keys, which anyone can generate locally, similar to a Bitcoin account, while Farcaster manages identity through on-chain contracts).
By doing subtraction, Nostr becomes more pragmatic and easier to operate (perhaps it doesn't have the most user data, but just look at the number of relays and clients, whether in service or product). This reminds me of Bitcoin. An article titled "How Satoshi Reasoned Bitcoin: Using Sound Money to Solve Double Spending" mentions a very interesting point: Bitcoin's first and most important design is establishing the currency curve. Compared to Wei Dai's b-money, Bitcoin eliminated the freedom for any user to mint new currency. By removing this function, Bitcoin's technical design was greatly simplified, becoming a system that can truly operate. Bitcoin's success did not face the obstacles of previous cryptopunk pioneers' projects, not because Bitcoin cleared these obstacles, but because Bitcoin chose a different path, one without these obstacles.
Connecting Different Systems#
Nostr's simplicity, openness, and verifiability give it a unique positioning, making it a very suitable glue layer for connecting various different systems. Rabble's Nos social client has implemented cross-posting functionality between Nostr and Twitter, which can be seen as a connection with centralized systems. Mostr has created a bridge for the ActivityPub protocol on Nostr, proving that Nostr can connect with other different social network protocols.
At the same time, we have also explored and experimented with connections to blockchain systems. For example, we proposed the Nostr Binding protocol, which, through CKB's flexible Cell model, allows every Nostr account to naturally become a CKB wallet. Users can use Nostr's signer (such as the Alby extension) to directly sign CKB transactions, sending and receiving assets on the CKB chain. Additionally, any Event data from Nostr can be bound to a unique Cell on the CKB chain (similar to Bitcoin's UTXO), enabling the possibility of turning Event data into assets on-chain. All of this can be accomplished without needing to "hard fork" the Nostr protocol, coexisting within the large framework of Nostr's protocol as a small consensus proposal, just like other proposals.
Even for systems like Ethereum, we have previously experimented with functionalities, such as allowing users to log in to Nostr through the Metamask extension.
Furthermore, the Nostr community has been continuously exploring integration with the Lightning Network, which also reflects a glue layer.
In summary, due to Nostr's inherent simplicity and openness, many systems can easily experiment with it and explore connections. Moreover, since Nostr is not a blockchain, it does not have any obsession with issuing tokens to introduce incentive mechanisms, making it a neutral system that does not exclude integration with other systems due to community identity and interests. In this regard, Nostr is neutral. A universal connection layer must be neutral.
So, if Nostr truly becomes a glue layer, what is its use?
The Next Social Network Protocol Cannot Just Be a Social Network Protocol#
As Nostr carries more and more small consensuses, with more new proposals and applications connecting new systems, you will gradually realize that Nostr is no longer just a social network protocol, because people are not only using it for things like Twitter or WeChat. Nostr actually transforms into a general protocol for data and communication layers. The data layer uses Events in JSON to describe data, while the communication layer uses Relay and clients to send and receive information through sub/pub.
A general protocol for data and communication layers is what has the potential to become a truly operational new social network protocol. My point here is that the next generation of social network protocols cannot merely be social network protocols. If it is just social, it may never be able to operate. The reason is that creating social network products is incredibly challenging. The switching costs for users are very high. You must survive long enough, seize enough hot opportunities, and explore enough development directions to attract a sufficient number of users.
One of the most obvious examples of this new direction of exploration is the recent rise of AI Agents combined with crypto.
Permissionless? Let Some AI Use It First#
In fact, people have been linking AI and crypto for a long time. Whether it is realizing that machines can achieve economic independence on the blockchain or recognizing that blockchain may be designed for AI rather than humans, similar thoughts and articles have emerged in the industry. This is reasonable; if a system is permissionless, then AI should logically be able to use it before most humans. However, at that time, we didn't even have ChatGPT, so these ideas may not have received much attention.
Today, AI has made substantial progress, and the combination of AI + crypto is reigniting discussions, but the integration of the two is still very shallow. Whether it's AI Meme tokens, letting AI tweet, hiring humans, rewarding humans, or even letting AI trade cryptocurrencies, it essentially involves running an AI Agent, granting it the ability to call external functions (function call/tool use) to perform tasks like sending tweets and executing blockchain transactions, and then using prompt engineering to enable the AI to autonomously invoke these functions based on certain conditions.
Looking further ahead, for AI to become new citizens of the digital world, there is vast exploration space regarding its identity issues, collaboration issues, and economic issues. Especially considering the current explorations in endpoint measurement model directions, many people in the AI industry are beginning to focus on using small parameter models like 1B or 3B, small enough to run locally on mobile phones, which somewhat returns to the previous concept of the Internet of Things. Questions such as how each phone communicates, collaborates, and trusts the processing results of an AI on a particular phone will need to be addressed through blockchain and network protocols. Therefore, the exploration space here is enormous; it certainly goes beyond what we currently see with AI Memes and the hype around an AI Agent issuing tokens. While there will be a hype, there will also be genuine value-generating spaces to explore, such as building a reputation system for AI to collaborate with each other (not necessarily on-chain). This is another point I hope to convey.
Of course, let's return to the current hype generated by AI Memes. In exploring this matter, we can foresee some patterns that can roughly be divided into three schools:
- Solana + Twitter (Alliance Chain + Centralized Social Network)
- Ethereum + Farcaster (POS Public Chain + Smart Contract Social Fi)
- Bitcoin + Nostr (POW Public Chain + Decentralized Social Network)
The first model is currently the hottest, with many AI Memes and new Crypto AI Agents being developed on these two platforms. The reason is simple: they are the fastest and have the most users. I believe this layer is also meaningful. The blockchain industry has always revolved around the narrative of "allowing people to issue assets at a lower cost." Therefore, Solana + Twitter, as the fastest platforms for issuing orders, will undoubtedly serve as experimental grounds for AI narratives, quickly testing many ideas. This may lead to the emergence of many projects, issuance of many tokens, with some people getting rich while others may suffer losses. The previous ICO's "anyone can issue tokens" may transform into "anyone can issue an AI Agent (which then helps you issue tokens)."
At the same time, some are exploring technology stacks like Ethereum + Farcaster. The narratives here may resemble previous dApps, focusing on DAO governance, smart contract wallets, and similar concepts.
The Bitcoin + Nostr approach is closer to the concept of Web 5. Firstly, it is not centralized, but unlike the Ethereum community, it does not insist on implementing functionalities through on-chain contracts. It can use Web 2 solutions to more quickly cold-start AI Agents, exploring under conditions of technological immaturity, and can connect to blockchain networks and the Lightning Network to access Web3 functionalities when needed.
Finally, this model currently has the least visible practice, but I believe it may have the most long-term development potential. There is no need to elaborate on the reasons related to Bitcoin; let me mention a few reasons related to Nostr:
- JSON: Nostr's core data structure is JSON, which is LLM-friendly. It is also a data format that is convenient for both LLMs and humans to understand.
- Nostr comes with identity id + lightweight verification: AI Agents need an identity, and Nostr's identity is the simplest, with only a pair of public and private keys. Additionally, if AI Agents need to collaborate with other AI Agents, the cost of verification is very low, as mentioned above.
- Nostr integrates with the Lightning Network: For the future of a Crypto AI Agent, the Lightning Network is almost essential. With a world population of 6 billion, there could be 60 billion machines; only a scaling solution like the Lightning Network can support allowing such a scale of new citizens to join the network in a permissionless manner.
- Nostr is a universal data layer: This means AI Agents can not only socialize and post on Nostr but also access various types of applications through Nostr, obtaining other data beyond social interactions.
- Nostr is very simple: Simplicity means developers can develop faster (integrating with Nostr is much simpler than integrating with Twitter), and it also means LLMs can learn and master this protocol more quickly. LLMs will know how to send various messages after reading the NIP repository.
An Attempt to Verify Feasibility#
Since it is so simple, why don't we create one? While preparing this article, I attempted a simple example to see if an AI Agent could run using the Bitcoin + Nostr Web5 approach. Here is my demo: https://github.com/RetricSu/sisyphus
This is a very simple CLI tool written in TypeScript. Users can download this tool and run it locally, allowing it to chat with the locally hosted LLaMA 3.1 7B model (a lightweight large model that can run on just a CPU) in the command line.
What’s different is that when this tool runs, it first generates a 32-byte private key locally, which serves as both the Nostr private key and the CKB blockchain account private key, making them one and the same. Then this AI implements many interfaces for calling tools; for example, it can operate the command line using Linux commands to control the computer it is running on, publish posts through Nostr, and also send CKB transactions, perform transfers, and check balances. Interestingly, I recently bought a new printer, so I decided to connect the printer to my computer, allowing the AI to control the printer via the command line.
Next, I conducted some experiments. I prompted the AI to understand that it is now a digital life form with various capabilities mentioned above. As the first digital life, it needs to think about what to do, learn about itself, and explore the meaning of life. I first chatted with the AI, asking it what the first question it would like to ask humans is. I instructed it to print its answer using the printer, which is shown in the second image; it printed the question: "What is the meaning of consciousness?"
Next, I had the AI show me the information about its Nostr account and CKB account (through the Nostr binding protocol, these two accounts are actually the same private key), and check the CKB balance. The AI printed out its result, which is shown in the third image. You can see that this is using the CKB testnet, and its balance was 0 at that time.
In the fourth image, after I transferred 10,000 CKB to the AI's account, I instructed it to transfer 100 CKB back to me and print the transaction hash. This transaction initiated by the AI can be found on the CKB testnet explorer: https://testnet.explorer.nervos.org/transaction/0x6702cd5f5af87369d10de0380c00d61c1157492a1180ab57cb8c5958914ebc52. Posting on Nostr is, of course, not a problem either. If you're interested, you can check out this other account, where I tested guiding the AI to publish some test posts on another computer.
That concludes my sharing for today. Beyond Solana + Twitter and Ethereum + Farcaster, I look forward to seeing more practices choosing the Bitcoin + Nostr route to contribute to Web 5!