Yesterday I was browsing bountsr and discovered a new bounty by fiatjaf for adding "relay browsing" to clients. This is the bounty Coracle was born to claim! However, it's a problem I've been putting off for some time now, because it's a very hard problem requiring some real creativity. In this post I'll survey the state of the art, try to articulate my vague ideas about what needs to be done, and sketch some next steps toward realizing this goal.

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.