At first glance, comparing AO—an ultra-parallel computing system—and Nostr—a decentralized social protocol—might seem unconventional, as they appear to belong to entirely different realms. However, both can be viewed as “message transmission protocols,” which makes a comparison possible.

As protocols focused on message transmission, the core component is naturally the “message” itself. So, how are messages defined within AO and Nostr networks? What are their respective network architectures for supporting message transmission, and how do they integrate with other protocols? What are their positions, primary use cases, and future trends?

This article aims to offer a detailed comparison of the AO and Nostr protocols, examining how their structural designs influence their functionalities and providing a thorough analysis of these aspects.

1. Concept and Characteristics of Messages

1.1. Messages in AO

In the AO network, a message is the fundamental unit of information exchanged between network units (MU, SU, CU) or processes. Messages facilitate information exchange and coordination.

AO is designed as a message-driven asynchronous communication network. Initially, AO requires messages to initiate processes (such as launching a process), which can come from external users or other processes. Additionally, AO’s inter-process communication is asynchronous, meaning that the sending and receiving of messages occur independently of the sender and receiver. This allows the sending process to proceed without waiting for a response or acknowledgement from the receiver, significantly boosting the efficiency of AO’s parallel computing.

In AO, the asynchronous nature of message transmission and the lack of need for waiting make it ideal for managing large-scale parallel computing tasks. This enables various system components to operate in parallel without extended wait times for responses from other processes.

Each message in AO follows the ANS-104 standard from the Arweave ecosystem, a data packaging protocol. ANS-104 enhances data throughput by serializing multiple transactions into a single binary transaction. This protocol not only packages data but also includes fields such as owner, signature, target address, label, and data. This design supports a wide range of data types, including documents, images, audio and video files, games, data models, program code, and holographic states. Additionally, it supports data ownership and signature verification, ensuring data security and integrity.

These features of the ANS-104 standard are crucial for AO, enabling it to support diverse application scenarios for different data types. A standardized message format greatly facilitates efficient inter-process communication and seamless collaboration, improving storage and processing efficiency on Arweave. This allows AO to effectively establish data availability layers and data consensus, addressing its extensive application needs.

1.2. Events in Nostr

In the Nostr protocol, messages are structured as “events” using a JSON-based format. This format serves as the fundamental data object within the Nostr network.

The widely-used message structures are integrated into a common standard called the NIPs (Nostr Implementation Possibilities) protocol. This standardization greatly improves data processing and management, enhancing system interoperability and stability. Through NIPs, users can perform various operations and interactions on the Nostr network without concerns about data format inconsistencies.

The JSON structure in Nostr defines the event format with various fields, each serving a specific function. For example:

• pubkey Field: Represents the public key of the event sender, used to identify the user. This public key signs the event digitally, ensuring its authenticity and integrity.
• kind Field: Indicates the type of event, such as chat messages, wallet information, or user actions like recommending relay lists or performing specific operations.
• content Field: Contains the event’s content, supporting various data types like social media posts, articles, audio, and video. This field allows users to convey the information they wish to share.
• sig Field: Stores the event’s digital signature, created by the sender using their private key and verified by the receiver’s client using the corresponding public key. This signature confirms the event’s authenticity and integrity.

For a detailed description of the event data structure, refer to Nostr Protocol Content. The Nostr protocol offers a clear framework for sending, receiving, and verifying events, ensuring data security, consistency, and reliability.

In summary, an event in Nostr is a data structure that includes any content and is signed by users. This structure highlights Nostr’s role, features, and functions:

• Information Publishing, Storage, and Reception: Nostr’s use of JSON and NIPs provides an efficient data exchange and management framework, ensuring consistency and interpretability, and offering a stable and reliable communication environment.
• Client-side Verification: The data structure allows for client-side verification, eliminating the need to trust relay servers or third parties, and directly confirming the authenticity and integrity of events.
• Decentralized, Censorship-resistant Social Network: The design enables Nostr to function as a decentralized platform where users can freely communicate and share information without concerns about censorship or data tampering.

2. Network Structures Supporting Message Transmission

2.1. AO: MU/SU/CU Collaboration Network

The AO network consists of three modular units: MU, SU, and CU, which work together through messages and processes. Its network architecture is illustrated in Figure 2-1.

Figure 2-1: Modular and Collaborative Network Units Forming the AO Network Architecture (Source: AO Whitepaper)

In AO, a process is a computational unit. Starting an application on AO equates to initiating one or more processes, with the system allocating and scheduling resources like MU, SU, CU, virtual machines, and memory to execute the process:

• MU (Messenger Unit): Responsible for sending information to the appropriate SU for processing, then delivering it to CU for computation. Results are returned to SU, and this process repeats continuously.
• SU (Scheduler Unit): Manages scheduling and message sorting, uploading messages to Arweave.
• CU (Compute Unit): Receives messages, performs computations, and implements state transitions.

AO’s network structure and operation indicate:

• AO as a Message Transmission System: Messages are the core elements within the processes of AO, serving as the sole working objects for MU, SU, and CU. The entire process revolves around messages, making the process essentially the activity of running a collection of messages. This includes the complete sequence from receiving messages, transmitting messages, scheduling and sorting messages, executing computations (message state transitions), to outputting and storing computation results. Therefore, AO is a message transmission system that can be dedicated to building applications focused on information publishing, real-time communication and interaction, content distribution, and more, such as decentralized social networks, social media, and decentralized audio/video on-demand/live streaming platforms.
• AO as an Ultra-parallel Computing Network: AO operates as a modular network where computations are performed off-chain, free from the constraints of block consensus. This allows computing units (nodes) to scale infinitely as needed, significantly enhancing computational performance. In the AO environment, an arbitrary number of computing tasks (parallel processes) can be initiated simultaneously. These processes can run independently on different computing nodes and complete local validation. This makes AO a distributed, verifiable ultra-parallel computer.

Even though each computing process can run independently on different nodes, they can communicate and collaborate through a unified message format (ANS-104). This method connects independently running computing processes into a unified network.

• AO as an Open Platform: At its core, AO is an information protocol that allows different applications running on Arweave to communicate with each other. Each application can send information to other applications through the AO network, utilizing AO for compositional operations and enabling cross-chain information exchange. The AO network operates off-chain and can seamlessly connect with Web2 applications. By invoking the AO protocol interface, Web2 applications can participate in this decentralized network. This feature allows AO to bridge the gap between Web2 and Web3 applications, facilitating trusted information exchange and interoperability between applications. The communication protocol design of AO makes it an open platform, offering developers limitless possibilities.

In conclusion, AO’s network architecture supports a composable, interoperable, scalable, verifiable, decentralized, and open computing platform. It is suitable for applications focused on information publishing and interaction, as well as those requiring high computing performance and complex logic, such as machine learning, autonomous agents, graphical rendering, online gaming, and DeFi.

2.2. Nostr: Client-Relay Structure

Nostr stands for “Notes and Other Stuff Transmitted by Relays.” The network comprises two main components, as shown in Figure 2-2.

Figure 2-2: Nostr Network Structure

• Client: This is an application running on the user’s end, designed to read and write data to relay servers. The client uses a public key as the address for the user to send and receive events, while the private key is used to sign events when they are sent. This signing process proves that the operation was performed by the user and prevents tampering. When receiving events, the client uses the private key to verify the signature, ensuring the event’s origin and integrity.

The client allows users to connect to any number of relay servers located in different places. Users can publish information on one relay and retrieve it from another. This means that the client (user) does not have to rely on any specific relay server, effectively protecting user data and actions.

• Relay Server: A relay server has the ability to listen to, capture, and store events from connected clients, and then forward these events to subscribed clients. Anyone can run a relay server, and multiple relay servers can serve as alternatives to one another. This design diminishes the importance of any single relay, reducing the risk of single points of failure and enhancing censorship resistance. Additionally, competition among multiple relays can drive improvements in service quality, such as offering greater storage capacity, faster response times, and spam filtering services.

Relay servers can choose to store all or part of a user’s content based on their own needs and decide on the duration for which the data will be stored. This provides greater flexibility in the relay’s positioning and commercial activities. At the same time, there is no need for relays to communicate with each other, which eliminates consensus issues and the need for data synchronization. Instead, data synchronization is achieved through the sending and receiving of events between clients, fundamentally different from blockchain nodes.

This architecture not only enhances system flexibility and efficiency but also effectively addresses various use cases and demands.

In summary, Nostr’s lightweight Client-Relay structure enhances system flexibility and efficiency. It supports a decentralized, censorship-resistant, and verifiable information publishing system, meeting needs for free speech, smooth communication, and data security and privacy. This design effectively addresses the shortcomings of centralized social media, making Nostr a popular choice for developers of decentralized social applications like Damus, YakiHonne, Iris, and others.

3. Integration with Other Protocols

3.1 AO + Arweave: The Decentralized World Computer

AO functions atop Arweave, seamlessly integrating with it as depicted in Figure 3-1.

Figure 3-1: Seamless Integration of AO with Arweave (Source: AO Whitepaper)

This represents an application of the Storage Consensus Paradigm (SCP). This novel paradigm effectively decouples storage (consensus) from computation, facilitating off-chain computations alongside on-chain consensus. The benefits of this approach are substantial:

• High-Performance Computing: With smart contract computations occurring off-chain, AO avoids the constraints of on-chain block consensus. This boosts computational performance significantly, making high-performance computing a reality.
• Ultra-Parallel Computing: Nodes can independently execute parallel tasks and perform local validations without the need for all nodes to synchronize and complete redundant computations, as seen in traditional EVM architectures. This capability enables AO to achieve ultra-parallel computing.
• Customizable Computation: Arweave offers permanent storage for all instructions, intermediate states, and computation results, functioning as AO’s data availability and consensus layer. Each application’s execution is intricately tied to the data stored on Arweave, allowing for customization based on the specific needs of local nodes. This level of flexibility surpasses the traditional EVM model, where nodes must execute predefined operations simultaneously to maintain network-wide consistency.

In essence, AO enhances Arweave with ultra-parallel computing capabilities, while Arweave provides AO with storage-as-consensus. Together, they create a decentralized world computer, opening the door to extensive innovation in the decentralized space.

3.2 Nostr + Lightning: Crafting Decentralized Information and Value Networks

Nostr, developed by fiatjaf, natively supports the Lightning Network due to fiatjaf’s involvement in its development. The Lightning Network, a second-layer solution for Bitcoin, extends blockchain functionality off-chain through channels. This effectively addresses Bitcoin’s issues of slow transaction speeds, limited throughput, and high transaction costs, enabling frequent and low-cost micro-payments.

A direct application of Nostr and Lightning Network integration is the implementation of “zaps” in social applications. The widely-used Nostr client, Damus, incorporates Bitcoin Lightning Network payments, allowing users to easily make a one-time payment for Lightning Network relay by entering a Nostr public key. After the payment, users receive a Lightning Network invoice. For a detailed walkthrough, visit: https://nostr.how/zh/zaps.

In terms of asset issuance, Bitcoin’s layer-one Taproot Assets (TAP) protocol is compatible with the Lightning Network, allowing the integration of Taproot assets and Bitcoin’s smallest unit, Satoshis, into the Nostr ecosystem. This facilitates immediate and cost-effective asset transfers via the Lightning Network, enriching Nostr’s asset variety and expanding possibilities for social networking, payments, and DeFi applications.

Additionally, CKB community members have proposed a Nostr Binding Protocol, leveraging RGB++ technology to achieve isomorphic binding of Nostr Events with CKB CELLS. This allows users to create and distribute native assets within the Nostr network, addressing native payment challenges in social networks effectively.

Crucially, the synergy between Nostr and the Lightning Network is ushering in a new business model for decentralized applications known as Value for Value (V4V).

The V4V concept argues that monetizing non-scarce information is a complex task. Traditional online monetization often relies on advertising, which depends on centralized monitoring and user behavior analysis. V4V provides an alternative by enabling the free flow of information and value without intermediaries or restrictions. This approach not only offers a novel way to monetize digital content but also introduces new methods for content creation and value transfer.

V4V solutions are adding significant value to Nostr-based social applications, podcasts, and live streaming platforms, such as:

• YakiHonne: A decentralized media interaction protocol integrating Nostr with the Lightning Network, using SATS for tipping. Annual payments have exceeded 90 million SATS.
• Nostrwatch.live: A decentralized live streaming platform running on Nostr and the Lightning Network, establishing a “Value for Value” two-way exchange. Streamers receive SATs payments from viewers in real-time, with the stream ceasing if payments stop. This differs from traditional prepayment models, eliminating the need for subscription or prepayment.
• Podverse: A Podcasting 2.0 app that integrates with Alby, using the Lightning Network to send boostagrams (messages with donations) and SAT payments to podcasts. The app streams Satoshis to the podcast being listened to based on per-minute listening time.

The Nostr-Lightning integration is transforming Nostr from a decentralized information network into one that combines information and value. This shift not only safeguards individual speech but also ensures personal asset security, making it a medium for value exchange. This evolution presents new possibilities for scalable and consumer-grade applications, potentially offering a viable path to widespread Web3 adoption.

4. Conclusion: Structure Determines Function

This article has analyzed and compared the AO and Nostr protocols from the perspectives of data structure and network structure, adhering to the principle that “structure determines function.” We explored the primary functions and application scenarios of each protocol:

From the Data Structure Perspective: AO and Nostr both serve as information transmission protocols supporting various data types for publishing, communication, and distribution. They enable the creation of decentralized social networks and media applications with features like decentralization, censorship resistance, signature verification, and privacy protection.

However, there are key differences. Nostr’s focus is on applications specifically designed for information transmission, which is just a subset of AO’s broader functional and application capabilities. AO emphasizes ultra-parallel computing, covering a wider and deeper range of applications.

From the Network Structure Perspective: AO’s network structure is modular, collaborative, and scalable, allowing processes to run independently on different nodes and perform local validation. These characteristics lay the groundwork for ultra-parallel computing.

AO’s seamless integration with Arweave, based on the SCP paradigm, overcomes the blockchain technology trilemma. It scales storage and computation resources as needed and utilizes Arweave’s permanent, ownership-protected consensus data for inter-process information exchange and collaboration. Consequently, AO can build a global, high-performance, ultra-parallel computing network, fostering innovation in both Web3 and Web2 applications.

For example, AO supports machine learning applications needing large language models (LLMs) and intensive computing; AgentFi applications with complex business logic, predefined needs, and varied autonomous strategies; ContentFi for copyright management and content monetization; and decentralized applications requiring cross-chain communication, asset transfer, data sharing, and smart contract interoperability.

In contrast, Nostr’s network structure, consisting mainly of Client-Relay components and Event data structures with public and private key systems, establishes a lightweight information network. When combined with Lightning, it integrates decentralized information and value network characteristics, making it ideal for scalable, consumer-grade applications.

From the Protocol Positioning Perspective: Although both AO and Nostr are message-passing protocols, their focus and positioning diverge. AO aims to build foundational infrastructure for a “decentralized world computer,” targeting lower layers but providing extensive application possibilities and capturing broader value.

Conversely, Nostr was initially designed as a lightweight decentralized social protocol, focusing specifically on social applications.

In summary, AO and Nostr offer distinct features and advantages in data structure, network structure, and protocol functionality, each with different positioning and use cases. Their unique attributes will manifest in their respective developmental trajectories.

References

1. Is AO an Ethereum Killer and How Will It Drive the New Blockchain Narrative?
2. AO Protocol: Decentralized, Permissionless Supercomputer
3. Nostr Protocol
4. Nostr Binding Protocol
5. Value4Value
6. Decentralized Social Protocol Nostr and Its Innovative Applications

Disclaimer：

1. This article is reprinted from [web3caff]. All copyrights belong to the original author [DanceChange]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.