What is NOSTR?

I’ve recently started looking at decentralized social network options. They promise resistance to censorship and central control. One such network, or rather protocol, is NOSTR, which is an acronym for Notes and Other Stuff Transmitted by Relays. It’s adoption and potential is a function of its simplicity:

1. Users generate a private/public key pair as an identity.
2. Content is published via websocket to one or more relays. Signed with the private key.
3. Content is requested via websocket from one or more relays. Verified with the public key.

That’s pretty much it. While there are also some standards that define the JSON format for particular messages; the above list adequately summarizes how the entire network functions. When you ‘follow’ a user, in it’s simplest form, your NOSTR client will add them to a local list and request their content from the relays you are connected to. The users public key will be checked against each signature to ensure the relays aren’t ‘lying’ to you. By publishing and requesting content via multiple relays, one relay is not a single point of failure or control.

Current Drawbacks

This is a good start and the simplicity is a key selling point. Simple technology can be adopted by developers and users much faster. I wrote a simple C++ NOSTR relay in a few hours myself: nostr_relay_lite. However, there are still some shortcomings when it comes to absolute full decentralization and central control resistance:

1. Reliance on Relays.
2. Reliance on the DNS (Domain Name System).
3. Reliance on ISP (Internet Service Providers).

Reliance on Relays

The first obvious issue is that if all relays you publish to refuse to serve your content, none of your followers will be able to receive your content. Perhaps a powerful entity could enact pressure on the relays for them to do so. The solution, of course, is running your own relay. Unfortunately this introduces complexity and brittleness. You will have to set up and maintain a server while simultaneously broadcasting its existence. Other relays, already censoring your other content, would prevent the propagation of your endpoint.

Reliance on DNS

If you’ve begun hosting your own Relay, chances are you’ve put it behind a domain name. Unfortunately, the DNS system, controlled by a few select, organizations could easily ‘delist’ you. To prevent his you will have to use a raw static IP address instead of a domain name. This has its own obvious drawbacks.

Reliance on ISPs

So, you’ve stopped using DNS, and now you’re in the clear, right? Wrong. Your ISP could still cut you off. Just as with DNS or Relay providers, if enough pressure was enacted, your internet access could be pulled and your relay server would not be able to serve your content. This is the hardest layer of the network to ‘fix’ with current technology and infrastructure. I don’t have any actionable ideas here.

Looking Forward: Building A Decentralized Holy Grail

There is one big theme here: servers are the problem. For the purpose of decentralization, in an ideal world, users would communicate directly with each other; each client simultaneously functioning as a client and relay.

Peer-to-Peer communication technologies have existed for quite some time and could be leveraged to address this, each user effectively hosting a server and a client simultaneously. There are networking tricks such as hole-punching to connect to devices directly behind NAT (Network Address Translation). Another technology to look at, as it has browser support, is WebRTC, although it currently requires an external channel for the initial connection. Perhaps it could be extended to allow one-way connections to open ports. IPv6 also might help here, as every machine could theoretically be granted a unique public IP address.

Now regarding DNS, we can switch to a decentralized alternative. Rather than use the centralized DNS system managed by ICANN, clients could switch to using blockchain-based DNS. This would allow P2P relay owners to ‘publish’ the information needed to directly connect to their host machine. Even without a static IP address, a dynamic DNS feature could update this record as your IP address changes locally. An alternative to blockchain could be a DHT (Dynamic Hash Table) with private key signatures to ensure resolved IP address and port is approved by the user. This, however, would not allow for human-readable DNS and would simply be a mapping of public keys (identities) to IP addresses. Additionally, without a blockchain where there are codified rules for updating the ledger with payments, nodes could simply refuse to propagate your DHT entries, thus allowing for censorship.

Finally, what about ISPs? No good answers here, unfortunately. The only solution would be build out a WLAN/Bluetooth Mesh Network that covers majority of the population. Devices would connect to one another directly via a wireless network and transmit packets (Prior art: FireChat, Amazon Sidewalk). This would be a huge challenge logistically and technologically; mesh networks are hard to scale. And just to add a touch of paranoia; some wired and line-of-sight links would also be necessary in the case of radio frequency jamming.

Theoretically, one could build an integrated ‘NOSTR appliance’ that would allow connection to the mesh network, with a DDDNS (Decentralized Dynamic Domain Name System) or DHT (Decentralized Hash Table) and P2P networking built-in. This would allow non-tech users to link into this new ‘freedom network’; you just buy the product and get online; fully decentralized. Of course, this would not just be great for resisting censorship, but providing communication and connectivity in times of emergencies. To further remove centralization, this unit would ideally be powered via locally generated electricity to prevent your power provider from cutting off your ability to communicate.

I want to finish off this post by saying that the value of decentralized systems is not only in their use, but in their existence. Having them standing by provides pressure on incumbent centralized systems not to push their luck when it comes to policy and enforcement. Perhaps decentralization to the level I’ve described here is not necessary, but somewhere between what we have now and my theoretical NOSTR appliance, is a decentralized system that is possible and practical.