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.

What it ain't

That fact was brought home to me this week as I worked for the nth time to repair the damage my refactoring did to the public chat feature in Coracle. This was the first feature I added as a response to popular demand and hype over a new NIP being added to nostr, way back in December 2022. Coracle was (I believe) the first general-purpose client to support public chat, which I hoped would bolster its notoriety.

I don't know if it helped Coracle's popularity, but it has cost me several weeks of development time in maintenance and abstraction cost since it was introduced. While it wouldn't be hard to apply the same content filtering work I've added to feeds in Coracle to chat, I'm not sure I want to continue to have my time stolen by sunk cost. And with the increasing frequency with which chat groups are being hijacked by spammers of various kinds, I no longer have the option of leaving chat alone.

So I've decided to remove group chat from Coracle. The implementation is still available, at chat.coracle.social, but unless a wild maintainer appears, it won't be receiving any updates for the foreseeable future. Chat was never a goal of my project, and while it may be one of the more popular features of Coracle, it's one of the least crucial.

This is just one of many illustrative features. In the same release in which I removed chat, I also added a background music player for kind 1808s. This is equally frivolous — but even more fun. It will likely live for a while, and disappear again someday.

Set a course for ???, warp speed

Now that Coracle is basically working™️ I need to take a step back and figure out what I want it to be. Even if I don't know where I'm headed, I'm still moving pretty fast. In order to make the best use of my grant from OpenSats, it's imperative that I at least have a mission statement.

In explaining to Vitor why I was removing chat, I accidentally articulated a pretty good one:

nostr:nevent1qqsfwxqv4qq5ajdx8yaksg2fwcw0enpykxvkl9kf2meqgheaq7f3ycgpz3mhxue69uhhyetvv9ujuerpd46hxtnfdufeeexz

The reason for this emphasis comes from the people I originally set out to build for: my church community. These people are generally not "internet-native". They aren't active on reddit, twitter, discord, twitch, tiktok, or youtube. To the extent they use social media, they post pictures on instagram, and buy and sell goods on facebook marketplace.

The features required to support a facebook analog are fairly obvious, and include event calendars, private groups, and marketplaces. However, there are a few dimensions to the problem that make building such a product more challenging than building a twitter clone.

Product complexity

One of the most consistent pieces of advice I've received about building a facebook clone is: don't. Facebook succeeded because it bundled multiple standalone tools into a single interface, and tied them together with a single social graph.

This is one of the things nostr solves — no longer do you need an everything app, if you can use micro-apps on an everything protocol. When I built zephyr last week, I was again stunned at how powerful building on nostr is. In half a day I put together something that would be impossible with traditional technologies — because if you don't have the ability to produce content on a centralized platform, you don't have the ability to consume it either.

But protocols feel different from platforms, especially for the layman. The other half of facebook's value add is (was) a simple and intuitive user interface, which not only made the different components available, but made them accessible as well. I don't think micro-apps, web app stores, or nostr browsers are complete solutions to the UX problem. Nothing can replace a design tailored to your specific end user.

Privacy and parochialism

Social graph partitioning is an essential part of designing a social network. In twitter-like applications, an an effective strategy might be described as "whatever". In other words, as long as you are able to 1. connect to the people you want to follow and 2. discover new content, you're fine — there's no need to be exhaustive or exclusive.

But tighter-knit communities require exclusivity. And by "community" I should qualify that I do not mean a reddit-style common interest, but a real locus of interdependence — whether intellectual, economic, or familial. You don't self-select into true communities except by way of a long (sometimes very long) probationary period.

But, as we learned from mastodon's failures, people are also members of multiple overlapping communities simultaneously. This means that an application designed to serve a person in multiple roles across multiple communities needs to be able to address those differing social circles according to their permeability. Enforcing community privacy using encryption might be appropriate for very tight groups like families, while other groups might want more lax rules about content sharing or member admission.

On nostr, relays are an excellent primitive for implementing access controls, and may be sufficient for all but the most private communication. I've also experimented with encrypted groups (nostr-in-nostr), but the juice might not be worth the squeeze — the additional complexity of gift wrapping might not be necessary if relays can be trusted not to leak data.

Two different approaches to group-specific relays could be used, depending on the level of trust required for the community: an Uncle Jim model where one or more admins host the infrastructure, or a virtual relay model where the group admin creates a private space on commoditized infrastructure.

The value of decentralization at a small scale

Now, of course if you have admins, you've basically opted back in to siloed, centralized platforms, unless shared identity is a value add. Single sign on could be attractive, but not overwhelmingly so — I think the thing that makes an identity shared across multiple platforms compelling is the ability to cross-post.

Unless content is protected by encryption, this is always possible, and would be very good for end users. Allowing content from outside a group to be pulled into a group allows the group to comment on it using its own idioms and values. It also enables loose coupling between weakly-related communities (for example a church and the town it is located in).

This would work very well for community groups, which aren't usually too picky about driving engagement, but would work less well for publishers or media brands, even if cross-posting of content would be beneficial to their curated communities. Instead of increasing the value of your community, it could be seen (and exploited) as advertising for competing siloes.

Multiple types of engagement

Finally, there are multiple types of relationship that might be emphasized to a greater or lesser degree in one community vs another. Facebook-style "friends" are generally less focused on ideas, and more on maintaining relationships. I wouldn't want to read what my mom posts on social media, but I do want to stay in touch with her. In contrast, twitter-style "follows" are more oriented towards the flow of information itself, rather than relationships. An application directed at handling both types of "community" would need to respect the difference between the two.

Toward something, anything

With all that in mind, here's an attempt at articulating my vision for Coracle, loosely based on the EOS model (no, not that EOS).

While my focus above has been on individuals as members of real-life communities, in practice many of these groups can be defined by a common interest in a given content "publisher", which is a more concrete (and practical) use case. This might be something as big as a newspaper, or as small as a substack or patreon. The content provides something for members of the group to talk about.

It seems to me that groups that are not content-focused operate in much the same way, except that topics are selected by group members, rather than by administrators. So the general strategy would be to build a product that can be used more informally by primarily targeting content publishers.

Core Values

1. Real life > digital life
2. Inorganic advertising is cancer
3. Encourage purposeful engagement
4. Different communities should be distinct, but mutually beneficial

Mission Statement

To enrich the social media experience of individuals in their capacity as members of multiple overlapping real-world intellectual, economic, or relational communities.

Target Market

Small publishers who want to create a place for subscribers to interact with the publisher's (public and paid) content and one another. Media brands who are open to the benefits of cross-posting across siloes.

What does it look like?

• Anyone can create a group hosted on self-hosted or commodity relays, or a mixture of both.
• A mixture of public and encrypted content for a given group
• Cross-posting of public content between groups
• Private content exclusive to group members
• Multiple tiers of group membership
• Configurable access control: admins, moderators, write access, read access
• Invite codes, including referral discounts/rewards
• Integrated calendar events (public and private)
• Integrated marketplaces (publisher merchandise or peer-to-peer)
• Support topical threads (oriented around publisher content) and member microblogging

Goals

• A relay implementation that supports virtual relays with all required access controls
• A group spec that supports granular content permissions and visibility
• An end-user interface that supports browsing multiple groups and non-group content
• An admin interface for group administration
• White-labeled configurable client implementation

Addendum: Ditto

Alex Gleason has been working on Ditto of late, which is first of all a way to reconcile ActivityPub and Nostr using a server implementation that supports both protocols, but which has the interesting side effect of marrying the siloed, exclusive ActivityPub model with nostr identities. This could be a good solution for branded clients and tighter community control, especially since it allows for the use of existing tools from ActivityPub's more mature ecosystem.

I intend to keep a close eye on Ditto as it matures. I hope that even if the two projects have a significant amount of overlap, that the problem space is big enough to allow for variations in execution, especially since Coracle has the ability to be fully nostr-native.

Conclusion

If you're currently a user of Coracle, don't worry too much, I won't be making any drastic changes anytime soon. I do think that the twitter-like, group-independent part of nostr is valuable, at least as a supplement to more cohesive communities. However, in order to achieve such an ambitious project, I'll have to exercise the discipline to remain focused and cut out any fat that accumulates. We'll see how I do.

Long story short: you know what happened. Did Biden steal the election? Would Trump have won if the NY Post article hadn't been suppressed? These are questions that history is not likely to answer. But was social media acting as a propaganda arm of the state? Yeah.

Follow the White Rabbit

So in November 2020, I tried to answer for myself the question: "What alternatives to Twitter are there"?

See, I won't name names here, but my local church community had gotten some press from a handful of large mainstream media outlets in the months leading up to the election, mostly related to our protestation of Covid tyranny and the hysteria that fueled it. These protests culminated in a couple of arrests, all of which were (years) later thrown out by a federal judge as being clearly in violation of our first amendment rights.

So you might see how I would be concerned about what we Christians would refer to as "persecution" coming down the pike, beginning with our freedom of speech. Luckily, the rot has advanced more slowly than I originally feared, and we are not all residents of the gulag as yet. I know some people would laugh at this, saying that Christians are privileged and dominant in our western world. To them, I would say: "fasten your seat belt Dorothy, 'cause Kansas is going bye-bye."

My survey of Twitter alternatives wasn't encouraging. While I didn't go as deep as Rabble, I think I hit most of the high points, the highest of which was Scuttlebutt, which has some hard limits to scaling. So I shrugged my shoulders and said, "hopefully somebody comes up with a solution".

I guess I'll do it

A year later, I did another survey of the decentralized social media space, and it looked exactly the same. At that point I realized "hey, I'm somebody", and in January 2022 I wrote the Blazepoint white paper. In it, I outlined the problems with current social media alternatives, and an innovative way to solve them using a novel multi-master architecture! I knew this was a huge project with an approximately 0% chance of success, so I committed to working on it for the next ten years.

Of course, unknown to me our good friend fiatjaf was already laboring away on a very similar protocol named after an ostrich or something. Two weeks or so after I wrote my white paper I came across Nostr, which had a very similar design. After unsuccessfully attempting to convince fiatjaf (via an extremely buggy DM implementation on branle) that my protocol was better, I went back to refining my protocol on my free nights and weekends.

If you look at the Blazepoint repository, you can see that the last commit was on May 23rd, 2022. Life had gotten busy, and while I still fully intended to keep my commitment to myself, as it turns out building a protocol by yourself is not easy. So in November of 2022 I threw in the towel, and dove headfirst into Urbit!

No, Just Kidding

I lasted about four hours with Urbit before thinking "ain't nobody got time for this". My resistance to the allures of Nostr folded, and over Thanksgiving break while my kids hung out with my wife and her family, I sat in a freezing RV feverishly coding the first version of Coracle. If you want to play around with it, you can still access it at here. I also have a screencast uploaded here. It basically works!

Late in the week, I pushed my work in progress to Github, and immediately got a message from fiatjaf about it. He wanted to see my work! It wasn't at all ready, but I deployed it and showed it off.

Everyone was very complimentary, which made me even more motivated to work on it. That kicked off 5 months (and counting) of waking up at 4 AM multiple times a week so I could put in more time.

The rest, as they say, is history. Jack followed me on Twitter, and tweeted about Coracle. He later told me that being able to switch easily between Damus and Coracle is what originally hooked him! Interoperability FTW.

What's Next

It's now mid-April, 2023 and I'm finishing up a fellowship at FUTO — they gave me a generous grant of $20k to spend three months working on Coracle full time, and I've tried not to disappoint. But my time is drawing to an end, and I'm wondering what to do next — find funding and start my own company? Go back to my old job? Something in between? I've got a few irons in the fire, so we'll see which one hatches first.

Finally, I would be remiss if I didn't give God the glory for this journey. All along the way I have been pushed out of my comfort zone, and over and over God has "worked all things out for good to those who... are called according to his purpose" just in time, and in unexpected ways. Coracle is God's project, and I pray every day that he would "establish the work of our hands for us, yes, establish the work of our hands."

So here's to the next 10 years of Nostr (that's 6 months in real-world years)! 🥂

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.