This of course means that I broke compatibility with all the NIP 29 group clients out there, but I did it for good reasons. In this post I hope to explain those reasons, and speculate on how best to move forward with "relay-based" groups on nostr.

To give you some quick context, NIP 29 and my approach to groups (which I'll dub "relays-as-groups" for clarity) are very similar, with a fundamental difference. Both have chat, join requests, group metadata, membership, moderation, etc. However, the basic unit of a NIP 29 group is a random group id string, while the basic unit of a Flotilla group is a relay itself.

I believe this design difference emerged in part because of what we were attempting to build. NIP 29 groups tend to be more telegram-like, where groups function more like chat rooms, and users join each one individually. On flotilla, groups function more like Discord servers, or Slack workspaces, and users join an entire group of chat rooms at once.

"Relays as groups" has four major advantages over "groups hosted by relays".

Decentralization

First, using relays as groups supports decentralization better than hosting user-managed groups on relays.

(To be clear here, I'm not referring to client-managed groups, which is a whole different approach that we've experimented with in the past, both with NIP 72 communities and with NIP 87 encrypted groups. Both NIP 29 and relays-as-groups solve many of the consistency problems associated with attempting to have a linear, synchronous conversation across multiple relays. While both alternatives have a story for migrating or mirroring a group, both rely heavily on the host relay to not censor user messages.)

I know what you're thinking. How can reducing the number of relays improve decentralization? Relays were originally introduced in order to create redundancy and spread trust across many actors, creating censorship resistance. This model was difficult for many bitcoiners to wrap their heads around, because it's a very different kind of decentralization than what a blockchain delivers.

Communities are an essentially different use case from a broadcast network where content is delivered based on author or recipient relay selections. Every message to a community would have to be delivered to all members of the community. Sending each message to all members' personal inbox relays just doesn't make sense; there has to be some other inbox for the community to work off of.

Additionally, online communities almost always have moderators and admins. This is even true of very public, open types of communities, like subreddits. The only type of community that doesn't have moderators is one that emerges naturally from social clustering. And even in that case there is loose consensus about who is in and who isn't, based on the actions/follows/mutes of the participants, whether these clusters are huge or tiny. Socially-emergent groups are served well by chat applications or broadcast networks.

But the subset of online communities that do prefer to confer moderator status on certain members are essentially centralized. In other words, centralization and control is a feature, not a bug.

Now, that doesn't mean there don't need to be considerations around credible exit and removing/adding moderators over time. But the fact is that moderator-led communities are always under the oversight of the moderators at any given time, even if the identity of those moderators changes and their power is limited.

What this implies is that decentralization for moderator-led groups looks very different from decentralization for a broadcast network. There is nothing at all wrong with giving moderators full control over the group's communications (qua the group; DMs and public broadcast content between group members should happen outside the group's infrastructure, just as people also exist outside the communities they are a part of). What is important is that no one has control over groups that they aren't nominally the admin of.

In concrete terms, what this all means is that community moderators should self-host their infrastructure. This is the same principle as motivates self-custody and home servers, but applied to communities. If community leaders manage their own relays, this means that no hosting company or relay admin can de-platform their community. Centralization of network infrastructure in this case aligns with the trust structure of the group.

Applying this to our group dilemma, it's easy to see that NIP 29 groups are more vulnerable to censorship or data harvesting attacks by malicious relay admins, since many unrelated groups might live on a single relay. In contrast, if you treat relays as groups themselves, every group is forced to live on a separate relay, spreading risk across more hosting providers.

Now, this doesn't necessarily mean that many "relays" aren't "virtual relays" managed by the same hosting provider. So I'll admit that even "relay-based" groups don't completely solve this problem. But I think it will tend to nudge community organizers toward thinking about community infrastructure in a more self-sovereign (or community-sovereign) way.

Investment in Relays

While both NIP 29 and relays-as-groups rely heavily on relays to implement the features that support each specification, there's an important difference between the feature sets. In NIP 29, relay support is specific only to groups, and isn't applicable to other use cases. In contrast, every protocol feature added to support the "relays as groups" can be re-purposed for other types of relays.

Take join requests for example. NIP 29's kind 9021 events allow users to request access to a group, and that's all. Kind 28934 join requests on the other hand allow users to request access to relays. Which in the relays-as-groups model means group access, but it also means custom feed access, inbox relay access, maybe even blossom server access. In fact, kind 28934 was originally proposed at the beginning of this year in order to support a different version of hosted groups, but remains as relevant as it ever was despite iteration on groups.

The orthogonality of features added to relays to any specific use case will long-term result in simpler specs, and more interesting relay-based use cases being possible. Join requests are only one example. The same is true of 1984-based moderation, the proposed LIMITS command, AUTH, NIP 11 relay metadata, etc.

We already have web of trust relays, feed relays, archival relays, and many more. Being able to request access to closed versions of these is useful. Being able to signal federation between multiple instances of these, run by different people, is useful. And of course, relay metadata, reports, and LIMITS are self-evidently useful for normal relays, since they pre-date Flotilla.

I've always said that relays are some of the coolest and most under-appreciated parts of nostr. This doesn't mean that we should add every possible feature to them, but features related to data curation and access control fit really well with what relays are good for. For more on the role of relays and what features should be added to them, see my nostrasia talk Functional Relays.

Declarative vs Imperative

A common paradigm in programming is that of declarative vs imperative programming. Imperative programming focuses on "how" to achieve a given result, leaving "what" the code is doing to be inferred by the programmer. Declarative programming instead focuses on the "what", and allows some underlying implementation to solve the how. A good balance between these paradigms (and knowing when to use one over the other) allows programmers to work faster, make fewer mistakes, and produce less code.

Another way to look at this is that a specification should contain as much ambiguity as possible, but without compromising the system attributes the specification is supposed to guarantee. It can get complex when figuring out what attributes are core to the specification, since sometimes the "how" does actually matter a lot.

However, nostr in particular falls pretty far along the "declarative" end of this spectrum because of its decentralized nature. The only person who can say anything with any authority is the person who signs an event. This event is a "declaration", and any effects it has are necessarily up to the relays, clients, and people interpreting the event. However, what others do with an event is an expectation that must be taken into account by the publisher, forming a feedback loop. This dialectic is what creates stability in the protocol.

In more concrete terms, no one can "tell" anyone else what they have to do by publishing an event like you might in a traditional, centralized RPC-type system. Any event whose semantics are a "command" rather than a "fact" or "request" is broken unless the counter party is fully committed to carrying out the command. An example of a "command" scenario on nostr is NIP 46 remote signing, in which the bunker is the agent of the user making the request. If the bunker implementation fails to carry out a valid command initiated by the user, its interpretation of that event is objectively incorrect.

NIP 29 applies this same paradigm to relays, particularly in the area of moderation, membership edits, and group metadata. In other words, there are several "commands" which instruct the relay to do something.

This isn't necessarily a bad thing, but it does increase the number of things the interface between the client and relay have to agree on. A regular relay may accept an add-user request, but then do nothing with it, violating the contract it has implicitly accepted with the user. The solution to this is feature detection, which is a whole other API to be specified and implemented.

My ideal solution to this problem is to shift the semantics of events away from "commands" to "facts" - in other words, to make the interface more declarative.

In fact, we already have an interface for moderation that works like this. Many clients support kind 1984 "report" events. Users sending these reports have no expectations about how they will be used. They are a "fact", a declaration of opinion with certain semantics. Other actors in the network may choose whether or not to pay attention to these.

This same model is easily applied to communities. Without having to implement any feature detection (either for the relay's implementation, or for the user's role on that relay), anyone can simply send a "report". This goes into the black hole of the relay, and may subsequently be ignored, broadcasted, or acted on.

The really nice thing about this model is that because there is no expectation for "how" reports are to be interpreted, any approach to moderation can be used depending on relay policy or client implementation. In NIP 29, if you issue a delete-event, it either happens or it doesn't and if it doesn't, you have to explain the failure to the user somehow.

In the relays-as-groups model, e-tagging an event in a kind 1984 requires no user feedback, and therefore it can be interpreted however the relay prefer. This can result in insta-banning, manual review, thresholds based on number of reporters, a leaky-bucket social score algorithm, shadow banning, temporary banning, soft-moderation by allowing clients to request reports and respond to them by changing user interface elements, or anything else you can think of.

The reason I think this is important is that community moderation is a very hard problem, and baking certain semantics into the specification can result in the complete failure of the spec. NIP 72 should be considered an example of what not to do. Some NIP 72 communities have survived due to the dedication of the moderators, but many more have failed because of the rigid moderation model. We should try not to make the same mistake again.

Conclusion

Now, having said all that, I think there is actually a lot of value to NIP 29. What finally clicked for me this week after releasing Flotilla is that the two approaches are actually complementary to one another. One of the most common feature requests I've already heard for flotilla is to have more complete support for rooms, which are currently implemented as not much more than hashtags. Better rooms (i.e., "nested groups") would require: authentication, membership, moderation, and pretty much everything else that exists for the top-level group.

As much as I believe the relays-as-groups approach is superior to NIP 29 for top-level groups, it doesn't make any sense to try to "nest" relays to create sub-groups. Something like NIP 29 is needed in order to fully support rooms anyway, so I think the convergence of the two approaches is all but inevitable. In fact, fiatjaf has already merged a PR which will allow me to use the same event kinds in flotilla as exist already in NIP 29 clients.

There are just a few more changes that are necessary in order for me to fully adopt NIP 29 in Flotilla:

• NIP 29 feature detection
• Opaque ids for unmanaged groups prevent unmanaged groups from having human-readable names
• We need a mechanism for building membership lists without relay support
• Better handling for 9021 group join requests

I've opened PRs for each of these (linked above). Hopefully we can work through these issues and combine our powers to become the Captain Planet of group implementations.

In order to do this, users must be able to articulate "what" they are looking for, and clients must be able to articulate "how" to find that thing. This "how" is divided into two parts: building a request that will match the desired content (very easy), and selecting a relay that is able to serve that content to the user requesting it (very very hard).

Why guessing isn't good enough

As a concrete example, let's say the user wants to find everyone in their "network" who is using a particular topic. The process would look something like this:

1. The user clicks the "network" tab and types in the topic they want to browse. This is the "what".
2. The client then translates the term "network" to a list of public keys using whatever definition they prefer (Follows? WoT? Grapevine?), and builds a filter that might look something like this: [{"authors": pubkeys, "#t": ["mytopic"]}]. Any relay will happily accept, understand, and respond to that filter.
3. The client then has to decide which relays it should send that filter to. This is the ??? stage of the outbox model, which immediately precedes:
4. Profit

It may not be immediately obvious why selecting the correct relays might be difficult. Most people post to relay.damus.io, and most people read from relay.damus.io, so in most cases you should be good, right?

This approach to relay selection has historically worked "well enough", but it depends on a flawed definition of success. If you only want to find 90% of the content that matches your query, using the top 10 relays will suffice. But nostr is intended to be censorship-resistant. What if those 10 hubs have banned a particular public key? Nostr clients should (at least in theory) be 100% successful in retrieving requested content. Even if someone only posts to their self-hosted relay, you should be able to find their notes if their account is set up properly.

A naive solution to fixing the FOMO

A 90% hit rate results in a feeling of flakiness, even if users aren't completely aware of what isn't working. Feeds will be incomplete, quoted notes will be missing, replies will be orphaned, user profiles won't load. The natural response to the FOMO this creates is for users to "try harder" by adding more relays.

On the read side, this means clients open more connections, resulting in much higher data transfer requirements, with massively diminishing returns, since there's no reason to expect that a randomly chosen relay will have a substantially different data set.

One the publish side, this means that clients end up publishing more copies of their data to more relays. This approach has been automated in the past by services like Blastr, which don't store a copy of events published to the relay, but instead forward events to the top 300 relays in the network. This results in a two-orders-of-magnitude increase in storage required, and only makes the read side of the problem worse, since it reduces the uniqueness of the data set each relay stores. This in turn means that more duplicates are retrieved when querying relays.

Both halves of this approach are equivalent to guessing. On the read side, users are guessing which relays will have any arbitrary content they might ask for in the future. On the write side, users are guessing which relays other people might use to find their notes. It is a brute-force method for finding content.

Randomness results in centralization

In theory, random relay selection would result in a perfect distribution of content across all relays in the network. But in practice, this method of selection isn't random at all, but is strongly influenced by user bias in what constitutes a "good" relay. While some users may check nostr.watch for ping times, geographical proximity, or uptime, most will choose relays based on familiar names or other people's recommendations.

In either case, these biases are entirely orthogonal to achieving a higher content retrieval hit rate, except when bias in relay selection results in clustering — i.e., centralization. In other words, the kind of randomness exhibited by users when selecting relays actually results in pretty much everyone picking the same few relays. We see this same effect when people try to come up with passwords or seed phrases — human-provided randomness is anything but random.

Clustering improves the hit rate when requesting events (slightly), but it results in nearly as much centralization as if only a single relay was used — and a lot more duplicate events.

Something (anything) other than randomness

In early 2023, Mike Dilger introduced NIP 65 (now known as the "Outbox Model") with a problem statement in the spirit of the original description of nostr: "Nostr should scale better. People should be able to find what they want."

Historical note: NIP 65 was formerly known as the "Gossip Model", derived from the name of Mike's desktop nostr client, called "Gossip". This unfortunately created a lot of confusion, since gossip protocols work very differently from how nostr tends to work, hence the re-brand.

Before NIP 65, an informal standard existed in which kind 3 user contact lists also included a list of relays that clients could use as something similar to Mastodon's "home servers". This list included the option to only read or write from a given relay. Unfortunately, it wasn't really clear what the semantics of this relay list were, so different clients handled them differently (and many clients ignored them). Usually this amounted to user-provided static relay configurations, which resulted in the naive relay selection approach described above.

NIP 65 used a very similar format (a list of relay urls with optional "read" or "write" directives), but with a very important semantic difference: relays listed in a user's kind 10002 were intended to "advertise to others, not for configuring one's client." In other words, these relay selections were intended as a signal to other users that they should use certain relays when attempting to communicate with the author of the relay list.

I highly recommend reading the entire NIP, which is very short and easy to read. But the mechanics of the spec are very simple:

When seeking events from a user, Clients SHOULD use the WRITE relays of the user's kind:10002.

When seeking events about a user, where the user was tagged, Clients SHOULD use the READ relays of the user's kind:10002.

When broadcasting an event, Clients SHOULD:

• Broadcast the event to the WRITE relays of the author
• Broadcast the event to all READ relays of each tagged user

For the first time, we had a way to differentiate relays in terms of what content could be found where.

When looking for a note by a particular user, a client could now look up the author's write relays according to their kind 10002 event, and send its query there. The result is a much higher hit rate with much lower data transfer requirements, and fewer connections per query.

Making Outbox Work

There are of course some assumptions required to make this work.

First, the user must know which author they're looking for. This isn't always true when looking up a quote or parent note, but context and pubkey hints solve this difficulty in most cases.

The author must also publish a kind 10002 event. This may not always be the case, but clients should prompt users to set up their relay list correctly. This isn't really a flaw in the Outbox Model, just in implementations of it.

Additionally, the user's client must be able to find the author's kind 10002 event. This is the "bootstrapping" phase of the Outbox Model, during which the mechanisms the system provides for finding events aren't available. This requires us to fall back to randomly guessing which relays have the content we're looking for, which as we saw above doesn't work very well.

Other than guessing, there are a few different ways a client might find the relay selection event in question, each of which is applicable in different circumstances. In most cases, using one of a handful of indexer relays like purplepag.es or relay.nostr.band is a simple and efficient way to find user profiles and relay selections.

However, if an author's content has been aggressively purged from these indexers due to censorship, they obviously can't be relied upon. Even though the author in question hasn't been deplatformed from nostr itself (since he can always self-host a publicly accessible relay to store his content), he has been effectively shadow-banned.

To get around this, relay selections have to be communicated in some other way. Nostr has a few different mechanisms for this:

• If the author's NIP 05 address is known and properly configured (it may not be), clients can look up the author's NIP 05 endpoint to find some reasonable relay hints. Unfortunately, these are often neglected, and usually custodial, so they can run into the same problems.
• If the author's pubkey is found in another signed event found on nostr, relay hints can be a way to propagate relay selections through the network. This relies on implementations picking reliable relay hints which can be difficult, and hints do tend to become less reliable over time. However, this strategy is very effective in resisting censorship because it makes banning viral — if a relay wants to completely purge a particular pubkey from their database, they have to purge every event that references it, since events are tamper-proof.
• In extremis, relay recommendations can always be communicated out-of-band. This can be done using manual input, QR codes, DHTs, jsonl torrents full of kind 10002 events, or any other mechanism client developers choose to resort to.

Another, more technical assumption is that any given query can be fulfilled by few enough relays that a client can actually make all the connections needed, without running into resource limits. If you're trying to request content from 10,000 users across 1,000 relays, you're going to have a bad time. This was pointed out to me by Mazin of nostr.wine. He makes a good point, and it's definitely something to keep in mind. There are some mitigating factors though.

The first is that the current topology of the network probably won't persist forever. Because nostr is largely populated by self-hosting enthusiasts, the number of "tiny" relays is proportionally much higher than it will be if adoption picks up, even if the total number of relays grows. The trajectory is that nostr will drift toward fewer, larger relays, reducing the number of connections needed to fulfill any given query.

This is "centralizing", but it's important to understand that this isn't necessarily a bad thing. As long as there are more than one or two large hubs, there is user choice. And as long as it's possible to run a new relay, there is always an escape hatch. Nostr, like bitcoin, has no hard dependency on the biggest player in the network.

The other thing to consider is that there are lots of other techniques we can use to overcome the limits of the lowest-common denominator's limitations (mobile browser clients), including self hosted or third-party relay proxies. The trade-off here is that a little trust (aka centralization) can go a long way to reducing resource requirements needed to fulfill queries using the Outbox model.

If you're interested in more details on this topic, see this blog post.

That was a long digression, but there is one other thing that the Outbox model assumes to be the case. Even if the correct relays are found and connected to, they still may not return all desired content, either because they don't have it, or because they refuse to return it to the user requesting it.

This can happen if the publishing client isn't following the Outbox Model, if the author had migrated from one relay set to another without copying their notes over, or if the relay in question chose not to retain the author's content for some reason.

The first two issues can be fixed by improving implementations, but the question of policy is a little more interesting.

Relativistic relays

The Outbox Model is a mechanical process; it's only as useful as user relay selections are. In order for it to work, users have to be able to make intelligent relay selections.

Every relay has trade-offs, depending on its policy. 140.f7z.io would not be useful for long-form content, for example. Some relays might have a content retention policy that changes depending on whether you're a paying user. If you don't pay, you might find out too late that your content has been deleted from the relay.

So what makes a relay "good" for a particular use case? Well, it's complicated. Here are a few factors that go into that calculus:

• Is the relay in the same geographical as the user? Proximity reduces latency, but jurisdictional arbitrage might be desired. Users should probably have a variety of relays that fit different profiles.
• Will the relay ban the user? Do the operators have a history of good behavior? Is the relay focused on particular types of content? Is the relay's focus consistent with the user's goal in adding that relay to their list?
• What are the relay's retention policies? A user might want to set up an archival relay for her old content, or a multi-availability-zone relay so her notes are immediately accessible to the rest of the network.
• Does the relay require payment? Paid relays are more aligned with their users, but obviously come at a financial cost.
• Does the relay have policies for read-protecting content? If so, other users might not be able to find your posts published to that relay. On the other hand, some relays are configured to work as inboxes for direct messages, which can help preserve privacy.
• Does the relay request that users authenticate? Authentication can help manage spam, but it also allows relays to correlate content requests with users, reducing user privacy.
• Is the relay you use hosted by your client's developer? If so, you're in danger of getting banned from your client and your relay at the same time.
• Is the relay a hub? Using hubs can help smooth out rough areas in Outbox Model implementations, at the cost of centralization.
• Is the relay used by anyone else? One-off relays can be useful for archival purposes, but often won't be used by clients following the Outbox Model, depending on how they optimize requests.

There are lots of ways to approach the problem of helping users select relays, but it's an inherently complex problem which very few people will have the patience to properly address on their own. Relay selection is a multi-dimensional problem, and requires satisfying multiple constraints with a limited number of relay selections.

In the future, special-purpose clients might be used to help people build relay sets. Clients also might provide curated "relay kits" that users can choose and customize. Or, we might see an increase in hybrid solutions, like smarter relay proxies or client-local relays that synchronize using other protocols or platforms.

The Limitations of Outbox

Outbox is not a complete solution, not because of any of the caveats listed above, but because NIP 65 per se only addresses the question of how to index content by pubkey in a broadcast social media context. But there are many other scenarios for relay selection that Outbox does not solve:

• Community, chat, and group posts might be best posted to relays dedicated to that context.
• Direct messages shouldn't follow the same contours as public social media content.
• Topic-oriented relays, or relays serving a custom feed might be useful independent of who uses them.
• Relays focused on serving a particular kind of event, like music, long-form content, or relay selections, are useful independent of who reads from or writes to them.
• Certain clients might need to fulfill particular use cases by using relays that support certain protocol features, like search, count, or sync commands.
• Some events might not make sense to publish to relays, but should instead be shared only directly, out of band.

Some of these use cases might be solved by new specifications similar to Outbox that prescribe where certain data belongs — for example, NIP 17 requires users to publish a different relay list before they can receive direct messages, while NIP 72 places community relay recommendations directly into the group's metadata object. A reasonably complete list of different relay types can be found in this PR, very few of which have a canonical way to manage selections.

Other use cases might be supported more informally, either by relays advertising their own value proposition, or via third-party NIP 66 metadata. Still others might be supported by scoping the network down to only certain relays through explicit relay selection — this is how white-labeled Coracle instances work.

The basic idea here is that there are categories of events that don't have anything to do with where a particular person puts his or her "tweets". For every "what" on nostr, there should be a "how".

Keep nostr weird

Whatever additional systems we end up adopting for helping with relay selection, one thing is certain — people will continue to discover new, creative uses for relays, and we will always be playing catch up. This is one of the coolest things about nostr!

But it does mean that users will have to adapt their expectations to a network that partitions, re-configures, and evolves over time. Nostr is not a "worse" experience than legacy social media, but it is a version of social media that has itself been set free from the stagnant walled-garden model. Nostr is in many ways a living organism — we should be careful not to impose our expectations prematurely, leaving room to discover what this thing actually is, or can be.

If you enjoyed this post but want more take a look at the talk I gave at Nostrasia last year. I also wrote up a blog post at about the same time that addresses some of the same issues, but focuses more on privacy concerns around relays and nostr groups. Finally, I recently wrote this comment, which includes some details about challenges I've faced putting Outbox into Coracle.

This discussion gets complicated very quickly, so to begin, I thought I'd cover the two components that everyone thinks they understand first (relays and encryption), and move on to the one that combines the existing primitives in new and exciting ways (groups).

What even are relays, anyway?

If you saw my talk at Nostrasia, this section is just a re-iteration of it. In fact, I wrote this blog post before the conference to help me with my presentation. So hello, from the past.

Relays are dumb. They're just servers, which speak a particular protocol, and which implement some minimal logic to support that protocol. Relays have to be interoperable, which is why it's important to design new parts of the nostr protocol in such a way as to be backwards-compatible, and simple to implement.

As a result, relay development has historically focused on performance to the exclusion of new functionality. You can see this with the success of strfry and Will's adaptation of the underlying technique to nostrdb.

One of my favorite programming talks is Simple Made Easy by Rich Hickey, the author of Clojure. One of the points he makes in that talk is that object-oriented programming is such a mess because it "complects" behavior and state. Hickey's solution to this problem is to use functions and values rather than methods and state.

I think that this same mistake is one we are at risk of making with nostr relays. I'll come back to this in a bit, but keep that distinction in the back of your mind: separating data and behavior can lead to a much simpler and more robust system.

Despite the emphasis on interoperability, relays shouldn't all be exact clones. There are a few different ways relays can differentiate themselves, either by providing specific functionality, by storing different sets of events, or by exposing a different interface.

Added functionality

Some implementations have pushed features forward, for example rbr.bio which implemented the COUNT verb from NIP 45 early on. However, these efforts are usually either supported by special clients (like nostr.band or primal's caching service), or fail to gain wide adoption and are eventually abandoned. The result is that NIPs specifying optional functionality tend to die without sufficient user demand.

The reason for this is that if you're building a client that selects relays based on user preferences, it can't rely on functionality that doesn't exist on the majority of relays. Without widespread support, search results or feeds requested based on Primal's special syntax will be incomplete or fail entirely. As a result, clients often build proprietary solutions to these problems, increasing centralization risk.

Subtracted functionality

Relays are able to helpfully differentiate themselves however, by offering a subset of protocol functionality. For example, purplepag.es is a reliable source for profile data and relay preferences, but it doesn't require clients to do anything different in order to be useful. Instead, users can simply add purplepag.es to their relay list and instantly get a better experience. A similar approach many commodity relays take is blocking certain event kinds, for example 1059 gift wraps or NIP 94 image headers. This fortifies their particular purpose, which is to not support more exotic protocol features.

Other kinds of relays don't support this guarantee, for example relay.noswhere.com only supports search if the search term is not accompanied by a filter, responding to standard requests with "filters: not planned (non-search queries)". This can still be useful, but it is not a relay, because it requires clients to special case how it's used.

Data relevance

There is a different kind of differentiation relays can implement, based not on functionality, but on content. This is what I mean when I talk about "relay de-commodification". The value proposition this type of relay offers is not "we can do something no one else does", but "we have the information you're looking for".

There are two ways to accomplish this: content curation and access controls. The difference being that content curation is context-independent, and might be based on topic, keyword, or LLM analysis, while access controls only accepts content published by certain accounts. Several relay implementations and hosting providers (for example relay.tools) support both of these approaches, and of course it's easy to combine them.

Likewise, there are two ways for a relay to gain access to the desired data, leading to two different value propositions.

A relay that focuses on topical data might scrape the wider nostr network in order to ensure it is able to reliably serve everything relevant to its niche. This might be done using any number of heuristics, including filtering by pubkey, topic, or sentiment, but in any case the relay is not intended primarily to be written to, but to be read from. This is primarily an additive model, focusing on offering a complete view of the given topic.

Another approach is to let the data come to you instead of scraping it from the wider network by only accepting events published by certain people, or being the go-to relay for a certain topic. In order for this model to work though, there needs to be some way for the relay to keep this data to itself by preventing scraper-powered relays from harvesting its data. This effectively means that these relays will not only have policies for who can write to them, but also who can read from them. These might be the same set of people (for example with a community relay), or more people might be allowed to read from the relay than are able to write to it, as in the case of content producers who want a paywalled private social media enclave.

Keep relays weird

Most relay implementations expose their data over websockets in line with the spec, but this isn't actually inherent to the function of a relay. We've already seen several projects implement relays in-app for caching purposes. These relays don't usually go through the ceremony of spec adherence, but some (e.g. nostrdb) do.

Different transport mechanisms and hosting options are possible for relays, and would only require clients to use a specific adapter to get at them. Some examples:

• A relay running on your phone as a service that other nostr clients can share to reduce data storage requirements
• A relay running on a LAN, only accessible from a particular location
• A relay running via any other transport, for example radio or carrier pigeon

The idea I'm trying to get across here is that relays aren't necessarily websocket servers. More abstractly, they are a name attached to a set of events that can be accessed in a standard way.

So, what are relays?

To recap, here's my definition of a relay:

1. They correctly support standard functionality
2. They should only support additional functionality related to curating their data set
3. They may restrict the data types they accept and serve
4. They may restrict the data they accept and serve based on content or pubkey

One additional feature that isn't currently standard but ought to be is strfry's negentropy synchronization feature. This is the opposite of AUTH, which protects a relay's own dataset, in that it allows relays to more efficiently share their data with peers. A nice bonus is that it also allows clients to use their local cache more effectively as well.

Simple Made Easy

Going back to Rich Hickey's talk, separating behavior and state allows you to work directly with your data, freely implementing new behavior whenever you need to. This applies to sets of events stored on relays just as much as it applies to in-memory data.

One thing that makes this possible is cryptographic hash functions, which cleanly transform state into values - the difference being that "state" couples a name with data that may change, while a hash is a compact representation of immutable data. If two hashes of event ids don't match, they're not the same set of events.

How does this apply to relays? Instead of adding new behavior to relays directly ("methods"), we can instead call "functions" on a relay's data.

This function can be anything - a centralized server, client code, or a DVM - that takes REQ filters as input. The function gathers the needed data (maybe from a cache, maybe using a sync command, maybe from multiple relays for completeness), performs the transformation, and returns it. The result is that relays become simple, interoperable repositories for data, without limiting what server-side computation can be applied to events.

While huge search indexes and centralized servers have a cost in terms of centralization, I think DVMs solve this problem brilliantly - the common interface for this augmented behavior is open, and can admit anyone who wants to start competing for search, counting, recommendations, or anything else you might want to do with events.

As Alan Perlis said, "It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures."

Encrypted Messages

Nostr DMs were a huge mistake, and I want to do it again.

NIP 04 has some obvious problems, most notably metadata leakage. The cryptography also hasn't been audited, and has some potential theoretical attack vectors. I've been working with some other nostr devs on a new cryptographic primitive, which will be audited and hopefully result in a better foundation for future work.

But fixing the cryptography still doesn't fix DMs. Nostr is not really the right architecture for secure private messaging, because ratchets require state. Nostr is designed such that there are no hard dependencies between events, which are replicated across multiple relays. This makes it very hard to manage the kind of state that protocols like SimpleX or Signal require.

Even apart from the difficulty of implementing stateful messaging protocols on nostr, we have two other problems to contend with: metadata leaks and spotty deliverability. Both of these problems come from the reliance of nostr on relays, which generally are not trustworthy or reliable.

Metadata Leakage

NIP 04 is really bad. Anyone can see who you corresponded with, when, how frequently, and how much you said just by looking at the event. Vitor's NIP 24 chat proposal aims to fix this with gift wraps, which use ephemeral keys to obscure the sender, padding to obscure message size, timestamp randomization to obscure timing, and double-wrapping to prevent leakage of the signed message.

This is a big improvement, but there are other forms of metadata that are still visible. To start, the recipient is still visible, along with how many messages they have received and their general size. So you can tell if someone sends lots of messages, or not a lot, but that's about it.

If we don't assume relays are trustworthy though, there are all kinds of implicit metadata that can be used to infer information about the sender, including:

• Client fingerprinting
• Relay selection for publishing and queries
• IP address collection
• First seen timestamp
• Identification of users by AUTH
• Correlation of the event with other messages sent/received during a session

These issues are much harder to solve, because they are part of the process of delivering the message, rather than just constructing it.

Transport and deliverability

The key feature of nostr that makes it work is relays. Relays provide storage redundancy and heterogeneity of purpose with a common interface shared by all instances. This is great for censorship resistance, but everything comes with a tradeoff.

Completeness and consistency are not guaranteed on nostr. This is ok in a social media context, because there's no way to keep up with everything everyone you follow says anyway, and you can rely on interactions and algorithmic tools to catch you up on anything important you missed.

But with private messages, every payload counts. Receiving messages out of order, with a delay, or not at all can severely disrupt conversations between two people, leading to misunderstandings and worse. This is a common experience on nostr; even fiatjaf has expressed skepticism about the viability of private messages on nostr.

This flakiness comes from a combination of low relay quality and poor relay selection on the part of clients. Relays can't deliver messages if they can't keep up with clients, go offline, or drop messages (accidentally or deliberately). Likewise, clients can't find messages if they look for them in the wrong place.

Relays fixes this

Let me just put things into perspective really quick. Twitter DMs are not e2e encrypted, and weren't encrypted at all until earlier this year. Mastodon messages are not encrypted - instance admins can read everything. Facebook has e2ee messages, but only between normal users, not in communities, groups, business chats, or marketplace chats.

So while nostr's architecture is not sufficient to make secure encrypted communication a value proposition of the protocol in itself, there is a lot we can do to improve on the status quo. Because nostr has no admins, the only option for privacy of any kind is end-to-end encryption. Metadata leakage notwithstanding, nostr messages can be "good enough" for some definition of that phrase.

It's important to not just punt on making DMs available in a standard way, because there is an expectation that a complete social media solution will have a way to establish a private communication channel with someone else in the network. Otherwise you're stuck with public correspondence and link sharing in order to hop to another protocol.

Let's just assume that you agree with me at this point, and that until there is a javascript SDK for SimpleX or MLS, we're stuck with nostr DMs of some kind. So how can we reduce metadata leakage and improve deliverability?

Fixing Flakiness

Let's start with deliverability first. NIP 65's inbox/outbox model is great. While it doesn't fix deliverability on its own, if every relay recommended was in fact reliable, and reliably followed by clients, there would be a very clear indication of where a particular user's messages could be found. Neither of these things is really true right now, but I do think clients are moving in this direction. Hopefully we can educate users better on how to pick good relays.

There are some limits to this model of course. For example, if you want to read notes from 1000 pubkeys at once, your client will likely end up connecting to hundreds of relays unless it has a cap, in which case it will miss a lot of notes.

One clean solution to this problem is relay proxies. There are a few implementations, but the one I run at mux.coracle.social is a stateless proxy that uses a wrapper protocol so clients can still select and dispatch to relays. I originally built this to improve mobile data use by deduplicating events on the server, and it does that pretty well, although it currently does it in the most naive way possible.

Multiplextr currently does not qualify as a "real" relay based on my four rules, since it uses a wrapper protocol. However, a smarter implementation would be able to route requests and events effectively by relying on client authentication and filter analysis, without changing the protocol. This would also allow clients to completely offload the complex business of relay selection to its proxy. Clients would also be able to combine multiple proxies just like they combine relays - because proxies are relays!

Proxying Privacy

Another downside of NIP 65 is that it encourages clients to connect indiscriminately to hundreds of different relays based on tag hints, other users' preferences, and relays baked into bech32 identifiers. This is not only bad for battery life and performance, but also allows attackers to easily trick your client into to connecting to their relay so they can start analyzing your traffic.

The best way to defend yourself against nosy relays is to not connect to them at all. And the easiest way to do that is to only connect to relays you control (or trust), and let them do the dirty work for you.

With a proxy, even if you don't control it, you can reduce the number of parties who can snoop on your traffic by orders of magnitude. And since other people use the proxy too, your traffic gets mixed with theirs, making it much harder to analyze. Of course, the downside of using a public proxy is that the proxy sees all messages you send and receive, and the relays you select for each request. Even worse, an untrusted multiplexer can hijack an authenticated session, exfiltrating private data from protected relays.

A proxy you control (or trust, either via social relationships or economic ones) is the best of both worlds. This proxy could also do some smart things for you to improve privacy as well, for example:

• Delayed publishing of gift wrapped messages so relays can't guess as easily when the event was first seen.
• Closing and re-opening connections to reduce the number of messages sent over an AUTH'd session.
• It could block suspicious messages on the fly, for example spam or notes with phishing links.
• If an abundance of options are available for relay selections, it could randomize which relays are used, or avoid using less reputable ones.

So I guess what I'm saying here, is "run a node". But not just any node - in the early days of nostr there were a lot of people spinning up relays because they thought it helped decentralization. Well, as it turns out, just like in bitcoin you have to use your node in order for it to be useful.

Beyond DMs

I'm not done yet, though. What's the point of all this? Why put all this effort into "good enough" DMs when we could spend the effort adopting SimpleX or MLS (said Semisol, who lives rent free in my head)?

Well, because there isn't a single "best" DM option. As I've dug into the topic, I've discovered that a ton of tradeoffs exist between complexity, privacy, and scale. The way I understand it, there are three basic options here:

• One-to-one encryption. This is how both SimpleX and Vitor's group message draft works. It allows for things like ratchets to be added on top, and is fairly simple - but fails to scale because every message has to be encrypted separately for every group member, resulting in n*m messages, where n is the number of group members, and m is the number of messages sent.
• Encryption via shared key. This is how WhatsApp works, and it scales really well because messages don't have to be duplicated. And while it does support forward secrecy, it does not support post-compromise security, so it is significantly less secure.
• MLS has a unique hierarchical approach to managing keys, which improves the complexity of one-to-one encryption so that it's logarithmic rather than exponential. However, MLS is highly stateful and still has scaling limitations.

My takeaway is that there is no perfect solution. Ratchets are the gold standard, but can't really be implemented using nostr relays, since they frequently require servers to have very specific characteristics, like the ability to deliver messages in order.

The fact remains though, that social media needs encrypted messaging of some kind, even if we encourage users to bail to a more complete solution if they want to be truly private. And encryption is useful beyond small group chats - think of Facebook groups, which scale to millions of people and whose users have a much lower expectation of privacy. This is what nostr is good at - social data, whether encrypted or in plaintext.

Belt and Suspenders

For a long time I have waffled between two visions of how private groups ought to work. Should they be encrypted messages sprinkled across the nostr network like confetti? Or should they live on one or two relays in plaintext, protected by AUTH?

Both of these options have issues. Sprinkling encrypted messages across the network almost guarantees deliverability problems, since already many commodity relays block gift wraps. And that's ok! They have no obligation to store your encrypted messages.

Storing group messages in plaintext is also sub-optimal, even if it's on a dedicated relay. Of course we're not going for military-grade secrecy here, but it would be trivially easy through a bug, or even a client that doesn't know how to deal with groups, to re-broadcast events that should stay private. We could do something wacky, like strip the signature from events hosted on a relay, but if we're going to do something non-standard, we might as well do the best we can.

So why not both? Group messages should be encrypted, and they should be stored on a particular set of relays. Again, assuming the relays used are trustworthy, this fixes both privacy and deliverability problems, because it's very clear where messages posted to the group should go.

Promoting relays to trusted status has some nice, unintended benefits too. One common objection to using encrypted content is that it becomes hard to filter. But if a relay is trusted to store a group's messages, it can also be trusted to be admitted as a member to the group. This would allow the relay to decrypt events and filter them to respond to requests by authenticated group members.

Of course, this would violate rule #1 for relays, since they would no longer be supporting standard functionality, but a guy can dream, can't he?

Conclusion

When I started working on nostr I had no idea it would end up being this complex to accomplish what I set out to do. Building a twitter clone was only a first step to an MVP, but I always had my eye on the prize of serving my local church community, which doesn't give a sat about social media per se.

Private groups are important to me not because I'm setting out to support political dissidents or journalists (although I hope they find nostr useful too), but because I want to get my friends off of Facebook, and the only way to do that is to create private marketplaces, calendars, communties, and more.

The problem of relays

Relays are a problem. They are simultaneously an implementation detail that users don't understand and don't want to deal with, and the very soul of Nostr. So far, no client has unleashed the power of Nostr's architecture, instead focusing on ease of adoption by starting users off with a hard-coded set of relays. Users are then left to dig through their settings to change which relays they want to connect to. Others, like Primal, attempt to elide the concept of relays altogether and provide a unified view of the entire network.

Various nods to the importance of relays do exist in various clients however, for example:

• Amethyst shows pretty granular controls and stats on their relay list.
• Snort (and others) shows the list of relays other users connect to on their profile page.
• Gossip has all kinds of settings for how many relays to use, how smart to be about relay discovery, and more.
• Coracle shows which relays an event was seen on in the note's overflow menu, and asks new users to select relays during the onboarding process.

Other common patterns include: color-coding relays, differentiating between read and write relays, and auto-selecting relays different from the user's own selections in order to fetch context related to a given note or feed.

All of these are great features, but they are baby steps, and don't fundamentally address the problem (or realize the possibility) of allowing users to navigate between overlapping venn diagrams of relays and their content.

Let me tell you about my feelings

I think it's generally a shared perception that these half-measures aren't enough, but nobody really knows what to do about it. Even fiatjaf, who has relentlessly pushed development efforts towards surfacing relays admits in the bounty cited above, "The app should make it seamless to browse these various scenarios, I have no idea how."

I share this utter sense of bewilderment. I feel unmoored when I try to think what a user interface that fully embraced multiple relays would look like. Decades of using software with a single-master paradigm has broken my mind; designing something that could actually be used to seamlessly navigate between relays is a massive effort for my poor, tired brain.

The closest thing to a "vision" for what this would look like is what Arkin0x has built with ONOSENDAI: a vast, three-dimensional space that you can travel through. Although to solve the problem, they would have to use an address space focused on relationships between relays, pubkeys, and events, rather than event content simhashes.

This could be a workable approach, resulting in something similar to LN Insights, a browser for lightning network topology, which adds node capacity and clustering as additional dimensions. But it's also true that this type of visualization quickly becomes disorienting, and is far less familiar than a traditional user interface with buttons and menus.

There are examples of this kind of thing being executed successfully by tools like Figma which allow you to zoom in and out on your canvas to travel from one place to another. Games like Supreme Commander support zoom-to-navigate, in addition to showing multiple windowed views of the same game. Tools like Photoshop and vector graphics editors take a different approach and introduce an extra dimension by allowing you to group content into multiple layers.

Another way to think about the additional dimension that relays introduce is by imagining Nostr is a virtual world, with geography (relays), actors (pubkeys), and history (events). Users are mobile, and can travel at will through the world (unless denied access by a relay), viewing artifacts left by other users in the form of published events. The wrinkle is that events can happen in multiple places at the same time, or be replicated across space over time as events get re-broadcasted.

Take a look at the conversation I had with Arkin0x on telegram while writing this post for more ideas for representing Nostr in 3D space.

Back to flatland

In traditional user interfaces, relationships within the data model are not usually represented spatially, except in very purpose-built applications like UML diagrams or mind maps. Instead, space is taken up by an additional dimension: affordances for user interaction. Screens are designed according to functionality, and access to groups of those functions exist in navigation items or menus. Content is addressed by overlaying those groups of functionality either literally via modal dialogs, or dimensionally using "Uniform Resource Locators". There's no space left for representing the same address space in multiple dimensions, especially simultaneously.

So, what is required is either a new UI element or a re-purposed one that satisfies the same semantics as a checkbox group: a way to choose zero or more options for the same value. This isn't too hard, you could add a dropdown menu on feed views, and call it good. But this won't make any sense to users unless they know what differentiates relays from one another, and with 1,300 relays in the network and counting, it will be impossible to process that information without help from the software.

So, relays need to be filtered and grouped. This can be partly accomplished by giving good names and metadata to relays, but the important thing is the content that lives on a given relay, which might be analyzed using the social graph, textually, or using some other heuristic. Unfortunately, with the current culture of cross-posting for reach, relays don't differ substantially from one another. For now, filters and groups have to be user-generated, which creates a chicken-and-egg problem, because remember? we are trying to make it easy for users to navigate Nostr!

Maybe a good place to start would be to create a tool that would allow users to analyze for themselves the factors contributing to relay differentiation, as specified in this bounty. Then, those insights could be quantified and automatically integrated into a given client's implementation of groups and filters. Of course, that runs afoul of the problem of centralization.

Or, discovery could be built in to clients using crude tools like checkboxes, color codes, and modal dialogs, and as the network partitions and relays specialize due to scaling limitations users can begin to develop a gestalt for what kind of notes end up on a given relay. The naturally occurring social partitioning that would result would self-reinforce by allowing implementations to classify relay content by personalities or content central to content already hosted there.

Conclusion

This post has been far more stream-of-consciousness than usual, and for that I apologize. But I also thank you, dear reader, for helping me rubber-duck my way to profundity. Here are my take-aways (maybe yours are different):

• Multi-master content is a truly novel paradigm, and interface metaphors for surfacing it don't really exist.
• The semantics of multi-master match multi-select and checkbox list interface elements.
• Relays are not sufficiently differentiated to support intelligent filtering and grouping. Users cannot currently care about the distinctions between relays, because they don't currently exist.
• The concept of "layers" in tools for video/image/graphics editing is probably the closest thing we have to a metaphor for representing two-dimensional content in multiple dimensions. Layers correspond well to dialogs, and so a first pass at this problem might be to show a feed's content modified by relay selection in a popover dialog.

I'm sure I'm not the only one thinking about this problem, so please! Take a moment to leave a comment with your thoughts, opinions, or hallucinations.

Coracle now supports connection multiplexing, which can reduce bandwidth usage by over 90% depending on how many relays you use. It's opt-in for now, but you can set it up by going to Settings and entering wss://multiplextr.coracle.social as your "Multiplextr URL".

You can check out the source code and self-host the library using this link. If you're a dev and want to add client support for multiplextr, the library I built to support this use case might be of use.

Now, on to your regularly scheduled blog post.

The above announcement isn't irrelevant to what I want to talk about in this post, which is (broadly) the question of "how can Nostr remain decentralized and still support advanced functionality?"

This is probably the most common question articulated among devs and enthusiasts - is search centralizing? What about recommendation engines? COUNT? Analytics? The answer is yes, and responses range from "it'll be fine" to "nostr is already captured".

For my part, I'm not sure if this problem can be solved. Already we have a browser wars dynamic emerging among clients, and business models based on proprietary services and advertising have been publicly considered. For the record, I don't think conventional business models are necessarily bad. The world works this way for a reason and Nostr isn't going to change that by default.

Nevertheless, I want to see a new internet emerge where my attention belongs to me, and I'm not beholden to massive companies who don't give a rip about me. As a result, much of the work I've put into Coracle hasn't gone into fun features, but into things I think will help realize the vision of Nostr. This gives me FOMO as I watch others' progress, but if I don't stay focused on my vision for Nostr, what am I even doing?

I should be clear that this is not a judgment on the motivations of others, building for fun and profit is just as legitimate as building to idealistically realize the best of all Nostrs. However, I would say that it is every developer's duty to keep in mind that what we're trying to accomplish here is not a web2 clone.

Two, and only two options

With all that said, let's get into the meat of the problem. There's a false dichotomy floating around out there that we have two options for adding server-side functionality to the nostr ecosystem. Option 1: pack all required functionality into relays, eliminating the "dumb relay" model, and making it extremely difficult to run a relay. Option 2: keep relays dumb and the protocol minimal, allowing indexers, search engines, and recommendation services (which I'll collectively call "extensions" here) to profit by solving advanced use cases.

Both alternatives are obviously deficient. Relays need to be something hobbyists can run; requiring relays to fold in a recommendation engine or search index makes that much harder, and for every feature required, proprietary solutions will be able to build a bigger moat.

On the other hand, proprietary extensions will not bother to interoperate. This will result in an app-store-like landscape of competing extensions, which will redirect developer and user attention away from relays to extensions. If nostr is to succeed, relays must remain an important first-class concept. Aggregators and indexers that gloss over the differences between relays destroy much of the value an individual relay has to offer.

In either case, some components of the network will become too sophisticated for a layman to deploy. The only alternative is for a few professionals to take up the slack and grow their service as a business. But I think there's a way to squeeze between the horns of the dilemma.

It's all about routing

It seems to me that most people prefer the "extension" model of scaling functionality of Nostr as a pragmatic, market-driven alternative to the impossibility of requiring all relays to support all possible features. And I agree, the folks developing and operating more sophisticated tools should be compensated for their hard work.

The real problem with this approach is that not that extensions are competitive and specialized, but that they obscure the importance of relays by becoming gatekeepers for data by providing additional functionality. If a client or user has to select a search engine and ask it to return results for a given relay, they have given that search engine control over their results, when their trust really should be placed in the relay itself.

(I will say as an aside, that there are scenarios when the gatekeeper approach does make sense, like when a user wants to "bring his own algorithm". But this should be something a user can opt-in to, not a default requirement for accessing the underlying protocol.)

Here's my proposal: instead of requiring users to trust some non-standard extension to make decisions for them, flip the script and make relays the gatekeepers instead. With this approach, the addition of a single feature can open the door for relays to support any extension at no additional cost.

One of the most exciting aspects of Nostr is the redundancy relays provide. With Nostr, you don't need to trust a single entity to store your data for you! Why should you trust a single gatekeeper to route you to that data? Relays don't need to provide search or recommendations or indexing functionality directly, they can simply send you to a third-party extension they deem trustworthy.

This approach allows extensions to piggy-back on the trust already endowed in relays by end users. By allowing relays that are already aligned with end users to broker connections with extensions, they form a circuit breaker for delegated trust. This is more convenient for end users, and makes it easier to switch extensions if needed, since relay operators are more likely to have their finger on the pulse than end users.

It also enables cleaner business relationships. Instead of asking clients to create custom integrations with particular extensions leading to vendor lock-in, an extension provider can implement a common interface and sell to relays instead by offering to index their particular data set.

With this model, relays have the flexibility to either provide their own advanced functionality or delegate it to someone else, reducing the functionality gap that would otherwise emerge with thick relays without removing the ability for extension service providers to run a business, all the while keeping users and clients focused on interacting with relay operators rather than non-standard extensions.

Making it happen

The difficulty with this of course is that add-on services need to be identifiable based on functionality, and they must be interoperable. This means that their functionality must be described by some protocol (whether the core Nostr protocol or an addition to it), rather than by proprietary extensions. There will be extensions that are too complex or special-purpose to fit into this model, or for whom interoperability doesn't matter. That's ok. But for the rest, the work of specifying extensions will pay off in the long run.

This routing layer might take a variety of forms - I've already proposed an addition to to NIP 11 for service recommendations. Clients would look up what add-ons their relays recommend, then follow those recommendations to find a service that supports their requirements.

It also occurs to me having written my multiplexer relay this week (and here we come full circle) that it would be trivially easy for relays to proxy certain types of requests. So for example, a relay might fulfill REQs itself, but pass SEARCH requests on to a third-party extension and relay the result to the end user.

In either case though, a well-behaved client could get all the functionality desired, for all of the data required, without compomising the brilliant trust model fiatjaf came up with.

Conclusion

I think this is a very important problem to solve, and I think relay-sponsored extension recommendations/routing is a very good way to do it. So, please comment with criticisms! And if you agree with me, and want to see something like this become the standard, comment on my pull request.

What's encouraging though, is that despite the complexity of "social media", there is a surprising level of consensus on what needs to be done - within the Nostr developer community, differences are characterized more by emphasis than by direction.

Staying on mission

Instead of focusing on "problems to be solved" within the current system (e.g. content monetization or data harvesting), people who "get" nostr have made its core principles their own. Because these principles radically differ from the way things are done in centralized systems, they spawn a complex system of new affordances and limitations.

If I had to sum up what the core principle of Nostr is, I would say "individual sovereignty". Nostr is a social experiment that asks people to take responsibility for what they say (and sell, host, publish, promote). This topic has been explored ad nauseum by better writers than I using Bitcoin as a vehicle, so I'll avoid re-treading the same ground if I can, except to point out that the two key design decisions of the Nostr protocol, self-custody of keys and hosting spread across multiple relays, simultaneously entrust control to users and revoke certain entitlements users are accustomed to.

It's well- (maybe even over-) understood what the risks and benefits are of holding your own keys. And being able to either select or host your own relays, each with different purposes and characteristics, gives individuals a level of control over his own publishing platform precedented only by the World Wide Web itself.

Lies they tell

But there are a lot of things users lose when moving away from a centralized platform. The ability to edit, delete, block, and promote content are not what I'm talking about - the guarantees for being able to do these things on Nostr are weaker, but as long as someone can take a screenshot of your Tweet, or block Google's ads, or log in with a different account, the affordances provided by centralized platforms are conveniences at best, and illusory at worst - that is, unless we go full digital panopticon, with universal biometric authentication and DRM for our brains.

What is more interesting to me is how centralized social media platforms lie about what they essentially are. Twitter's motto is "what’s happening", and their about page features a tweet encouraging others to "Speak the truth, even if your voice shakes." And yet over the last several years they have censored real news, promoted propaganda, and shadow banned those whose "voice shakes". Musk's desperate claims that "we'll stop, I promise" don't negate the fact that Twitter retains control over users' speech in a way that is inherently in conflict with their stated mission.

This is true even of non-political speech, because it is in Twitter's interest to promote content that drives engagement, because engagement is what in turn drives advertising profits. This undermines their claim of user enfranchisement - they exercise partiality in choosing whose voice gets a megaphone.

Users of Nostr know the feeling of this weight being lifted. Nostr is anything but polished, but that's part of the charm - you know there is no one scanning your content, deciding who sees what and with what "added context". Many users including myself have experienced a 10x or more increase in engagement, despite a much smaller number of people on the platform. This is of course likely due not only to the lack of an algorithm, but also to the lack of celebrities, which tend to absorb attention, leaving little for the rest of us. But for now, Nostr is for the plebs.

Cutting the Gordian Knot

And I hope, and have reason, that it will continue to be so. When I spoke to my pastor prior to moving to Austin to work on Coracle full-time, I asked him what problems related to social media he would like to see solved. He said that he would like to see a solution that puts users in control of their algorithm, and allows individuals to broadcast their content to as wide an audience as possible.

There is a contradiction here, and the claim that it can be solved is one of the main lies that centralized platforms like to tell. You are free to broadcast your data as widely as you want, but no one is obligated to read it. Twitter tries to square the circle by artificially reversing this trade-off, resulting in a system where "you can't broadcast your data unless we want to force people to read it." But even they can't give their users control while simultaneously taking it away.

There is a path forward though, and now we finally get to the point of this post. Nostr is so revolutionary because it puts "digital localism" within reach. I had better define my terms here, since "digital localism" is used to describe a lot of dystopian ideas I'm not very excited about. What I mean by the term is something like "social relevance". Contra the egalitarians, there are real differences that exist to set groups of people apart. Things like topical interest, physical geography, professional network, religious belief, and yes, ethnicity and sex.

What is a community anyway

The fact that digital "communties" exist is something that to their credit Mastodon recognized, and sought to accommodate. But they missed the fact that humanity is partitioned into a nearly infinite number of overlapping sub-groups based on a nearly infinite number of dimensions. Yes, maybe I should be friends with you because you also like cats, but let's refine this further, do you think cilantro tastes like soap, are you a member of the Church of Satan, are you Italian, have you been reading Hayak lately, do you like watching Hallmark movies, English, do you speak it? Partitioning people into groups based on a single dimension is an exercise in futility, and is the reason Mastodon instances are either ghost towns or home to millions of users.

By allowing users to download/host their own data and join as many and whichever relays they choose based on arbitrary criteria, people are now able to co-locate in digital space, and interact with each instance in a different way. This is why I'm not excited about tools that spray your data to as many relays as possible. This only serves to maintain the illusion that replicating all content across every instance can scale, and it can't.

Instead, relays should differentiate, both in terms of function and membership. In the future (and even now) there will be closed archival relays that scrape the network and provide a backup of user data for a fee; public-read, private-write relays that allow members to participate in an exclusive group with greater reach; private-read, private-write closed community relays; public "town square" relays, paid relays that provide indexes, full-text search, or content recommendations for the wider network (or a relevant subset of it); and relays that provide oracles for data external to nostr. The ability of users to pick and choose which relays to connect to (and to multiplex those connections through yet another proxy/aggregator relay) allows them to define their own low-granularity social graph, refining it further with follows, mutes, and other "algorithmic" tools.

The same is true of client implementations. Many people building social media platforms want to "fix Twitter". But that vision of digital society is amazingly narrow (luckily, Nostr developers don't seem to suffer from the same kind of myopia). Most people I know don't have Twitter accounts, or use them. For them, Twitter is about as relevant to their lives as CNN. Instead, they use private Facebook groups to arrange babysitters for their kids, or Cragislist to buy and sell local goods. They use Google maps to find reviews for nearby businesses, and the church email list to keep up with prayer requests. They subscribe to newsletters their friends publish, and spend their days at work sending memes over Slack. The common theme here is that all these platforms connect "us" with "mine", not with "them". And yes, journalism and topical interest ala Reddit is a part of this, but for normal people, a vanishingly small part. But let's stop squawking about "echo chambers".

And Nostr, despite its limitations, can be applied to every use case enumerated above. In so doing, it will free regular people from the constraining force of opinionated, artificial, centralized communication platforms, and allow them to build a digital social network that complements real life.

Conclusion

The driving force, for me, is not to erase our differences and create an egalitarian utopia, or stick it to big tech, or to make money, but to see the people I love, who belong to me, and to whom I belong, flourish by being connected with the people who belong to them, and to whom they belong. The resulting network will be characterized by high trust and high cohesion, laying a solid foundation for content and ideas to efficiently propagate across the distributed social graph, similar to how the lightning network routes transactions. But the key to making this work is to rise to the occasion, and take back our digital sovereignty by making it as easy for the average person to navigate the digital social landscape as they do in real life.