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 and moments like now that might feel a bit quiet. However, I still keep an eye on Nostr, not for any particular reason, just because I genuinely like it.
What distinguishes Nostr from other social network protocols? If the Bitcoin community has a P2P economic development model that differs from 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 at the Nostr conference, there was a talk titled Openness Is Nostr’s Killer Feature, which speaks to this point.
The openness referred to here not only pertains to whether it can technically allow functional extensions based on its design architecture but also includes whether the ecological and governance structure of the protocol itself is open. If you examine it from this perspective, you'll 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 this JSON format, meaning all data is an Event. Next, we agree that the activities across the entire Nostr network are essentially the back-and-forth transmission of Events between clients and servers (also called relays) that store data. This is the entirety of NIP01 (the proposal for the core Nostr protocol). Of course, it should be noted that NIP01 also includes a consensus that we agree that when the Event's kind 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.
Let me give a somewhat absurd example: suppose today I suddenly want to record every tree in the world and create a forest app to document things like the age, species, location, and growth conditions of trees, allowing users to upload trees they discover and view others' recorded trees. I could use Nostr to do this. I just need to find a new number as the value for kind, say 12345 as 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 larger Nostr protocol.
Others can continue doing what they care about, possibly operating as a social network like Twitter, while my app focuses on capturing, displaying, and sending this special Event about tree kind. This Event will coexist harmoniously with other Events in the larger Nostr network. Thus, 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 openness in the ecological and governance structure of the protocol? Does Nostr possess openness? Taking our forest app as an example, theoretically, governance of the Nostr protocol occurs in one place: https://github.com/nostr-protocol/nips. The NIP repository records all the major foundational consensus we just mentioned, as well as various smaller consensuses proposed by different individuals, such as our forest app being a small consensus. 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, outlining the specifications for the Event data used by the forest app, allowing others to adhere to this specification. If the administrators of the NIP repository agree and merge our proposal, it becomes an official sub-specification.
Some might think that this means the Nostr protocol is controlled by the administrators, who can merge or not merge at will. 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. Everyone openly debates every proposal that gets merged. If your idea is flawless and hard to refute, there’s no reason to prevent it from being merged.
- The second point, which is more important, is that whether or not something gets 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 proposes a new NIP but the governors refuse to merge it, it doesn’t have much impact; they can continue to serve their users with their client as long as relay operators accept this new Event, everything will function smoothly. If relay operators also disagree with this new Event and refuse to accept this data type on their nodes, assuming this forest app is indeed a good idea with many users, those users will seek out relay nodes that support this Event. Ultimately, if all relays resist this new Event, the forest app can also operate its own dedicated relay, thus solving the problem. Once the user base is large enough and this new Event is active enough in the network, other ecological roles will naturally consider integrating this Event.
Conversely, the same applies to relays. There’s a sense of carrying users to command the lords. The fundamental reason is that the ecological roles of clients and relays are interchangeable; clients can replace relays, and relays can replace clients, meaning no user is locked into one part, allowing them to make the best choices for themselves. Users will vote on these choices, using factual standards to retroactively influence 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 quite similar to Bitcoin's governance model. Bitcoin's POW allows governance to achieve a state of separation of powers, where code developers, miners running nodes, and coin-holding users constitute a system of checks and balances. The NIP repository of Nostr is like Bitcoin's 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 have little significance.
Verifiability#
The second aspect of Nostr that I find attractive is verifiability. A phrase we often hear in this industry is "Don’t trust, verify." In fact, many systems can be verified; the key difference lies in the cost of verification. For instance, as a currency system, Bitcoin's verification is straightforward; you just need to check whether the block hash meets the POW difficulty, while Ethereum's POS is much more complex, requiring you to search for and verify the signatures of all staked nodes and their voting processes, etc. 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 calculate the world state since every transaction can potentially rewrite the state.
For Nostr, the cost of verification is also very low. Each Event, as Nostr's data, is decentralized and independent. Anyone in the network can verify the correctness of a data piece by calculating whether the event id and signature are correct based on 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 in Ethereum, as we mentioned earlier, is actually 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 pair of public and private keys) because you can verify the signature.
Aside from 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 generated, while Scuttlebutt can achieve this through chain-like data signatures), or DID identity (Nostr's ID is merely 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 in terms of services or products to appreciate this). 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, and by removing this functionality, Bitcoin's technical design was greatly simplified, becoming a system that can truly operate. Bitcoin's success did not clear the obstacles posed by previous cypherpunk pioneer projects; rather, Bitcoin chose a different path, one without these obstacles.
Connecting Different Systems#
Nostr's simplicity, openness, and verifiability give it a unique positioning as a glue layer suitable 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 to 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 be a CKB wallet. Users can use Nostr's signer (like 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 larger Nostr protocol framework 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 and use Nostr through the Metamask extension.
Moreover, the Nostr community has been continuously exploring integration with the Lightning Network, which also reflects a glue layer.
Overall, due to Nostr's inherent simplicity and openness, many systems can easily experiment with it and explore connections. Additionally, because 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-scale 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 Twitter or WeChat-like applications. Nostr actually transforms into a general protocol for data and communication layers. The data layer describes data using the Event JSON format, 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 could potentially 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, catch enough hot opportunities, and explore enough development directions to attract a sufficient number of users.
One of the most obvious examples of exploring this new development direction 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 the blockchain may be designed for AI rather than humans, similar thoughts and articles have emerged in the industry. This is quite 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 weren't necessarily taken seriously.
Today, AI has made substantial progress, and the combination of AI + Crypto has begun to spark new thoughts, 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 basically involves running an AI Agent, granting it the ability to call external functions (function call/tool use) to enable it to send tweets and blockchain transactions, and then using prompt engineering to allow the AI to autonomously call these functional interfaces based on certain conditions.
Looking further ahead, if AI is to become a new citizen of the digital world, its identity issues, collaboration issues, and economic issues all have vast exploration space. Especially considering the current explorations in endpoint model directions, many people in the AI industry are starting to focus on using smaller models with 1B or 3B parameters, small enough to run locally on mobile phones, which somewhat returns to the previous concept of the Internet of Things. This raises many questions about how each phone communicates, collaborates, and trusts the processing results of AI on a particular phone, all of which will need to be addressed through blockchain and network protocols. Therefore, the exploration space here is enormous; it certainly extends beyond the AI Meme we currently see, where everyone is speculating around an AI Agent. There will be a wave of hype, but after that, there will still 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 sparked by AI Memes. In this exploration, some patterns we can foresee can roughly be divided into three schools:
- Solana + Twitter (Consortium 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, and 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 calling out, will undoubtedly serve as experimental grounds for AI narratives, rapidly testing many ideas. This may lead to the emergence of many projects, the issuance of many tokens, with some people making money and others getting burned. The previous ICO's "anyone can issue tokens" may transform into "anyone can launch an AI Agent (which then helps you issue tokens)."
At the same time, some are exploring a tech stack like Ethereum + Farcaster. The narratives here may resemble previous dApps, exploring concepts around DAO governance and smart contract wallets.
The Bitcoin + Nostr approach is closer to the concept of Web 5. First, it is not centralized, but it also does not insist on implementing functionalities through on-chain contracts like the Ethereum community. 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. The reasons for Bitcoin are self-evident, but here are a few reasons related to Nostr:
- JSON: Nostr's core data structure is JSON, which is a data format friendly to LLMs. It is also a data format that is relatively easy 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. Moreover, if an AI Agent needs 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 intelligent agents of this scale to join the network in a permissionless manner.
- Nostr is a universal data layer: This means that AI Agents can not only socialize and post on Nostr but also access different types of applications through Nostr, obtaining other data beyond social interactions.
- Nostr is very simple: Simplicity means that developers can develop faster (integrating Nostr is much simpler than integrating Twitter), and it also means that LLMs can learn and master this protocol more quickly. LLMs can read the NIP repository and understand how to send various messages.
An Attempt to Verify Feasibility#
Since it is so simple, why don't we create one? While preparing this article, I tried a simple example to see if I could run an AI Agent 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 download this tool, run it locally, and can chat with it in the command line using the locally hosted LLaMA 3.1 7B model (a lightweight model that can run on just a CPU).
What’s different is that when this tool starts, it first generates a 32-byte private key locally, which serves as both the Nostr private key and the CKB blockchain account's private key; the two are unified. Then, this AI implements many interfaces for calling tools, such as controlling the computer it is running on using Linux commands, posting on Nostr, sending CKB transactions, making transfers, and checking balances. Interestingly, I recently bought a new printer, so I decided to connect the printer to my computer, allowing the AI to control this printer via the command line.
Next are some experiments I conducted. I prompted the AI to understand that it is now a digital life with various capabilities mentioned above. As the first digital life, it needs to think about what to do, learn about life, and explore its meaning. I first chatted with the AI, asking it what the first question it would like to ask humans is. I had it print its answer, which is shown in the second image: "What is the meaning of consciousness?"
Next, I had the AI show me its Nostr account and CKB account information (through the Nostr binding protocol, these two accounts are actually the same private key), and check the CKB balance. The AI printed its result, which is shown in the third image. You can see that it was 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 had it 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 was also not an issue; 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 today. Beyond Solana + Twitter and Ethereum + Farcaster, I look forward to seeing more practices choosing the Bitcoin + Nostr route to contribute to Web 5!