Interpretation of Damus’ communication logic, the Myth of DeSoc

Cryptobricks Reports

2023-02-14 02:03

来源链接

订阅此专栏

收藏此文章

TL;DR

Damus is one of the applications on the Nostr protocol. It is the first lap-breaking product on the DeSoc track in 2023, with a DAU of up to 84.7k. In NIPs, the protocol realizes social decentralization through the lightweight design of relays and clients, and with the support of celebrity effects and mobile traffic portals, it has gained great attention in the bear market. However, I personally think that Damus, which is based on the Nostr protocol, still has not found a social scene that really fits Nostr, so after the heat dissipated, the DAU has dropped by more than 50%…

1/ What is Damus: Interpretation of Nostr Protocol from NIP

Last week, the Damus application on the Nostr protocol was all the rage, and there were countless interpretations of the protocol, but the interpretation of the code level was a little lacking. Nostr has an EIP-like proposal mechanism covering technical specifications for protocol upgrades called Nostr Implementation Possibilities (NIP). Therefore, this article will go deep into the underlying code and try to interpret the core interaction process of the Nostr protocol.

Damus implements the following NIPs 1:

NIP-01: Basic protocol flow

NIP-08: Mentions

NIP-10: Reply conventions

NIP-12: Generic tag queries (hashtags)

Among them, NIP-01 builds the core interaction process of the Nostr protocol, and event is a key object in the interaction:

{
"id": <32-byte lowercase hex encoding of the serialized event data via sha256>
"pubkey": <32-byte lowercase hex-encoded public key of the creator of the event>,
"created_at": <unix timestamp in seconds>,
"kind": <integer type, translated as kind, can be understood as "channel">,
"tags": [
["e", <another event ID>, <recommended repeater URL>],
["p", <other people's public key>, <recommended repeater URL>],
... // May contain other types of tags in the future
],
"content": <arbitrary string>,
"sig": <64-byte signature of the serialized event data hashed via sha256>
}

// UTF-8 is a variable-length character encoding for Unicode, which can be used to represent any character in the Unicode standard, and the first byte in its encoding is still compatible with ASCII.

// JavaScript Object Notation (JSON) is a standard format for representing structured data as JavaScript objects, often used to represent and transmit data on websites (such as sending some data from the server to the client, so it can be displayed on the web page).

In this code, the “serialized event data" in "id" and "sig" are UTF-8 JSON serialized strings (no spaces or newlines):

[
0,
<pubkey, (lowercase) hexadecimal string>,
<created_at, integer>,
<kind, integer>,
<tags, an array of non-empty string arrays>,
<content, string>
]

So far, the construction of the event the object is completed, and the user can already publish content on the Nostr protocol and sign it, then the next thing to do is to realize the communication between the relay and the client.

relay: It is the server set up by the protocol participants 2, which only stores and sends content, and only communicates with the client, which is the key to anti-censorship.

client: You can choose to connect to repeaters. Clients must connect to at least one relay to communicate, giving users the ability to filter information.

The subscription mode of the Nostr protocol means that the repeater will establish a continuous websocket connection for the client to connect 3.

After a client connects to a relay, the client can send three types of messages to the relay:

["EVENT", <"event" defined above>], for publishing events.

["REQ", <subscription_id>, <filters JSON>...], for requesting events and subscribing to new updates.

["CLOSE", <subscription_id>], used to stop the previous subscription.

Among them, the message of EVENT the type has been explained above, so it will not be described again. The REQ the type needs to send a random <subscription_id> and filters information to the relay, and the relay will return the information that meets the filter conditions in its server, track the subscribed public key, and send information to the same client when the information published by the public key in the future meets the conditions until the client overwrites the original <subscription_id> with a message of the type CLOSE, or the client sends a new message of the type REQ with the same <subscription_id>.

A relay can only send two types of messages to clients:

["EVENT", <subscription_id>, <event JSON as defined above>], used to send events requested/subscribed by the client.

["NOTICE", <message>] to send a human-readable error message or other content to the client.

As above, the core process of Nostr protocol interaction is realized. Users can choose relays according to their social preferences, create their own social scenes, and synchronize data in other Nostr applications through “private key import”. In addition, users can also build their own relayers (this can even be done in ordinary smartphones 2), and broadcast the URL of their own relays in a snowball manner, resisting external censorship and blocking.

Regarding the relay and client, throw away the code here for an abstract understanding:

1/ Information Transmission If Alice is connected to a relay A and Bob is connected to a relay B, even though both are on the Nostr protocol, they cannot communicate, they must be connected to at least one of the same relays (ie Alice to relay B or Bob can connect to relay A).

2/ Social Scene If the relay publishes content that they are not interested in (or spam), users can disconnect the relay from their client. But this user can still get in touch with another user in the relay that is disconnected by himself (jointly connect to another relay), so that the user can create his/her own social scene.

3/ Anti-censorship If relay A combines multiple relays and refuses to publish Alice’s “event”, then Alice has the right to choose other relays, or even create a relay by herself, and then tell relatives, friends and fans about the URL, through snowballing. In this way, Alice successfully avoided the joint “encirclement and suppression” of multiple relays.

Image source: Github (Nostr Client Feature List)

Get more information about the Nostr Protocol from Github…

2/ Interpretation of Damus’ communication logic

Celebrity Effect

On January 1, former Twitter CEO Jack Dorsey typed the phrase “Pura Vida” on his Twitter, which received numerous likes.

This Costa Rican phrase symbolizes simplicity and purity. What former Twitter CEO Jack Dorsey wanted was simple: a simple, pure social network.

Today’s social network applications are cumbersome, complex, and heavily commercialized, with a single company dominating the industry. This has caused dissatisfaction among all social app users around the world. As the founder of the world’s largest social platform, Jack’s vision for a decentralized network is far greater than we imagined.

On February 1, Jack announced the launch of Damus on Twitter, the first mobile client of the decentralized social protocol Nostr, becoming a new player in the decentralized social network. Meanwhile, Damus entered the App Store, and within a day it shot to the top 10 download charts in the App Store’s social media category.

Due to Jack’s status on social media, his Twitter post caused an uproar, and countless people rushed to imitate and download Damus. This became one of the reasons why Damus exploded overnight.

Traffic Entry

In December last year, former Twitter CEO Jack Dorsey threw 14 bitcoins (approximately $245,000 at the time) to fund the development of Nostr, an open decentralized social network protocol based on encrypted key pairs. Damus is just one of several Nostr projects in development.

The launch of Damus in the Apple App Store has not been smooth.

The delay in availability was largely due to the fact that the decentralized nature of Damus was somewhat tricky during the initial app review process. Apple has been requiring the app to follow the same rules as other social networks, without taking into account the nature of its open information access protocol.

The official Damus account had previously tweeted that the app had been rejected from the App Store multiple times, despite addressing the issues raised by Apple. But on February 1, the Damus app was finally approved.

Essentially, Damus is just an iOS platform client based on the Nostr protocol. In other words, Damus and even other Nostr clients are just entrances to this social network.

On February 3, Damus, a decentralized social networking application based on the Nostr protocol, has been removed from the App Store in mainland China.

Damus stated that he was notified that according to the request of CAC (China Network Administration), your APP would be removed from the China App Store because it contains content that is illegal in China and does not comply with the App Store review guidelines.

On the evening of February 3, VERTU, a British luxury mobile phone brand, sent an invitation to Damus on Twitter.

VERTU released a mobile phone called “METAVERTU” in October 2022. Its Metaspace operating system is specially designed for the decentralized application software DAPP of the Web3.0 ecosystem, returning digital sovereignty to users and project parties.

It is understood that Metaspace is currently vigorously inviting and developing excellent project parties in the Web3 field. Compared with Apple’s ruthless hegemony, VERTU has shown an extremely friendly gesture to the Web3.0 ecology.

Lightweight Design

NOSTR is a protocol through which many things can be established. This protocol is a relatively lightweight, simple but scalable open protocol on which a truly decentralized social media platform can be established. Lightweight design is mainly reflected in two aspects: the protocol layer and the application layer. At the protocol layer, there are currently only two roles in the NOSTR network, relay and client, which are only responsible for the transmission and storage of information. There is no design for the incentive layer, and the operation initiative is delegated to each node participating in the protocol. At the application layer, decentralized Twitter eliminates redundant information flows such as advertisements and promotions in Twitter, and focuses product development on creating personalized social scenarios through the subscribe function. Damus even though the game design is between the relay and the client, there is no room for advertisers, and the traditional project side-user economic model design is distributed between user-user through the relay and the client. It enables the two to explore the economic closed loop in the game.

This lightweight design facilitates the user’s understanding of the protocol and the application and further reduces the user’s threshold for use. Such a decentralized social network with no fees, no ads, and low barriers to entry, with the celebrity effect of KOL calling out and the blessing of mobile traffic portals, can naturally set off a storm in a calm bear market…

3/ Myths about decentralized social…

What is social? Its essence is information interaction between people. The traditional social model solves the need for timeliness of information transmission, but it causes:

Fragmentation of rights: Users have fragmented ownership of their own social data, manifested as having limited rights within a certain platform and not having the right to synchronize social data between platforms.

Concentration of power: The fragmentation of user rights leads to the concentration of power on the social platform itself, which has the “power of life and death” over the user’s social graph on its platform.

Concentration of risks: The gathering of power will inevitably bring about the concentration of risks. Once the central server storing data is attacked, the consequences will be multiplied.

The above problems are fundamentally caused by the centralized operation mechanism of the traditional social model, so Decentralized Social (DeSoc) came into being. Taking Nostr as an example, its public-private key system design enables the re-integration of rights separated from users, its social graph can be synchronized in the Nostr ecosystem, and when the API is available, it can realize cross-protocol dissemination of data. In addition, there are almost no threshold requirements for participating in the Nostr protocol to set up relays, and it belongs to a distributed structure. Therefore, when an existing relay fails, content backup or synchronization can be realized through the creation of a new relay, and then abandoning the failure or malicious relay.

Nostr undoubtedly solves the pain points of the traditional social model, but this is an innovation at the protocol layer. For Damus, its level of innovation as an application is not comparable to its recent popularity. As a “decentralized Twitter”, although in The Nostr protocol layer has begun to take shape to solve the economic problems of creators in the traditional social model (the distribution of benefits between creators and platforms, and the Matthew effect 4 between creators), but it has not been further reflected in Damus. In addition, I personally think that epoch-making projects will not claim to be “decentralized **”, but will create and meet new needs in new application scenarios. Therefore, exploring the application scenarios of users’ social rights outside the traditional mode is the first consideration that BUIDLers in this track should consider before starting projects. And I have to mention that although Lens provides an API for other DeSoc projects to synchronize data, there are still social barriers between the protocols, which runs counter to our original intention…

CryptoBricks Analyst: Orson, Skyi