In the 2017 whitepaper of ArcBlock, there is a component that has been overlooked, mentioned by very few people, and that is the "Decentralized Pub/Sub Gateway".
This component is actually explained in detail in the following section of the white paper, such as explaining its relationship with blocklets.
Even provided an explanation to illustrate how the decentralized pub/sub is implemented for different users to interact on a decentralized gateway.
Essentially speaking, this is actually a very simple component that uses a long connection protocol (mainly wss). Each node provides channels that users can join freely, which are communication channels. Users can communicate in the same channel, and these channels are scattered among different nodes, so users need to join different channels to communicate with other users in the same channel. We have also designed relay nodes (called super nodes) to connect different nodes to improve the efficiency of user discovery and communication.
The idea of Decentralized Pub/Sub Gateway is to design it very simple, handing over many specific tasks to the nodes themselves: Which channel to join? How to handle the message format? How to subscribe/aggregate/filter/organize messages? All of these are not taken care of because each decentralized application should be responsible for itself. Unlike centralized services, often the client is very simple and "thin," while a huge and complex server controls everything.
Now take a look, this idea and Nostr really have a similar design.
Nostr actually corresponds to a part of our architecture, the Decentralized Pub/Sub Gateway, and it concretizes its functionality, which is to create social applications, thus defining a set of Event data. We consider the Decentralized Pub/Sub Gateway to be more abstract, without defining what an event is, leaving it entirely up to the application to decide. Additionally, Nostr emphasizes message relay, which is a storage and forwarding mechanism, whereas the Decentralized Pub/Sub Gateway does not concern itself with these aspects and simply acts as a real-time forwarder. If message persistence is required, it must be implemented separately.
Most of the today's so called dApps actually have no decentralization at all, which is a sad fact. Many dApps should actually be called Blockchain apps, as they only use blockchain and treat smart contracts and blockchain as backend modules, without considering decentralization at all. Nostr is an example of a typical architecture for a decentralized application, and our Decentralized Pub/Sub Gateway is similar.