Some group specs have public listings with private groups, which would be the only way to know. Also, sadly I haven't been able to onboard my community onto nostr, because the software is just not there yet.
And it is now a custom feed in Coracle:
nostr:naddr1qvzqqqrujgpzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqyw8wumn8ghj76r0v3kxymmy9e3k7unpvdkx2tn5dahkcue0qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qg5waehxw309ahkumredehhgetn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg5waehxw309aex2mrp09skymr99ehhyee0qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qyfhwumn8ghj7ur4wfcxcetsv9njuetn9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qqgnydfsxv6rjveexcmnwwpsxcur2dsp3g7q8
I'm really enjoying the book we're currently reading, "Understanding Media" by Marshall McLuhan, written in 1964. I recommend it to anyone interested in deeply understanding technology from a very unusual angle (especially nostr:nprofile1qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszrnhwden5te0dehhxtnvdakz7qpqr0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgsn452r4 ).
nostr:nevent1qy2hwumn8ghj7un9d3shjtnwdaehgu3wvfnj7qghwaehxw309ashgmrpwvhxummnw3ezumrpdejz7qgewaehxw309a5x7ervvfhkgtnwdaehgu339e3k7mf0qywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uqzqwupshysup8j2e223xgz4csy98munzzn8ngyj4qd0ns9wzfc84fh6kjnul
This is a big part of my project, and a lot of what we cover in the book study episodes of nostr:nprofile1qythwumn8ghj7cnfw33k76twv4ezuum0vd5kzmp0qyvhwumn8ghj76r0v3kxymmy9ehx7um5wgcjucm0d5hsz9thwden5te0wfjkccte9ehx7um5wghxyee0qythwumn8ghj7ct5d3shxtnwdaehgu3wd3skuep0qyw8wumn8ghj7cmgwf5hxarsd9kxctnwdaehgu339e3k7mf0qy2hwumn8ghj7cm0wfskxmr99eek7cmfv9kz7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsqgxl78v8swd99cullfn0jccnlydssu6dftxdnnkvw8tclsh25uvk8g2xw7zq . I like your suggestions, but I think we'll have to go much deeper to really fix social media.
In the mentime, this is of course super difficult because we're already tackling decentralization, which is a big enough problem on its own. The good news is, the open protocol makes it very easy to build new clients that implement new, healthier ideas.
Cool, that was part of my vision with nip 32 originally, so that makes total sense. You could incorporate 10003s into that too, just with less granularity.
Anyone have tips and tricks to help this pleb recover his friend's stash?
nostr:nevent1qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzamhxue69uhhyetvv9ujumn0wvh8xmmrd9skctcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uq35amnwvaz7tms09exzmtfvshxv6tpw34xze3wvdhk6tcppemhxue69uhkummn9ekx7mp0qyfhwumn8ghj7ur4wfcxcetsv9njuetn9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyqfc2lhmm692dpzu6a9rrdx2k5x8jpkhm2jp4q5mcwth8nzls7qfu6yj68z
Key delegation and revokation (or even better, rotation) are badly needed, but NIP 26 isn't it.
Some recent discussion on the topic: https://github.com/nostr-protocol/nips/pull/1452
I'm sure your perspective on the problem would be very welcome.
Usually it's stored in the app/browser, hopefully never on the server. You can also use extensions like nos2x or alby to protect your key from the app, or you can use NIP 46 signers like nsec.app or Amber to hold your own keys and sign remotely.
No, you're mixing me up with nostr:nprofile1qydhwumn8ghj7un9d3shjtnwdaehgun0vd4k2apwdaexwtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz8rhwden5te0wfjkccte9e5xjemgd35kw6r5v4ezucm0d5hsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshszymhwden5te0wp6hyurvv4cxzeewv4ej7qgwwaehxw309ahx7uewd3hkctcprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszythwden5te0dehhxarj9emkjmn99uqzpkg3j83suqzyfw2zcr5zet28pve279chvnpzwklwp0vexal06sr4mc6r9l
Could someone ACK this PR so we can merge it?
https://github.com/nostr-protocol/nips/pull/1333
nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uqjqamnwvaz7tmwdaehgu3wv45kuatwv3a8wctw0f5kwtnnwpskxef0qyfhwumn8ghj7mmxve3ksctfdch8qatz9uq3yamnwvaz7tmwdaehgun4v5hxxmmd9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyrhprfwl7sxpnf247s07g26g7q8xrry3yftz9t3hkmptkeahd38yj4jvnvj nostr:nprofile1qyt8wumn8ghj7emjv4jkuum0w4kzuumsv93k2tcpzdmhxue69uhk7enxvd5xz6tw9ec82c30qy88wumn8ghj7mn0wvhxcmmv9uq3vamnwvaz7tmjv4kxz7fwd4hhxarj9ec82c30qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcppemhxue69uhhjctzw5hx6ef0qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg6waehxw309ahx7um5wgh8g6r9wdsk6etrv96zu6t09uq3wamnwvaz7tmpw3kxzuewdehhxarj9ekxzmny9uqzqqqqqqqgyll6499lag5gc00uu3pzc720hwtxykmtx85sf8mjn4cq8tul9r nostr:nprofile1qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qgmwaehxw309aex2mrp0yh8wetnw3jhymnzw33jucm0d5hszrnhwden5te0dehhxtnvdakz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uqzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqxg5cd
Death, Taxes, and Melvin calling nostr:nprofile1qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qgmwaehxw309aex2mrp0yh8wetnw3jhymnzw33jucm0d5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qy88wumn8ghj7mn0wvhxcmmv9uqzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vahj2kfz a tyrant
I've seen a lot of people asking for an explainer on the outbox model lately, so I went ahead and wrote something up. Take a read and let me know if there's anything missing so I can go back and improve it.
naddr1qvzqqqr4gupzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqq2nskt2w9vx6dznfdvj64rpw4mk5nmxf3v9xsd0gdy
Nostr is a mess. It always has been and will always be. That's part of the appeal! But it's important that users be able to navigate the rolling seas of this highly partition-tolerant network of kaleidoscopically-interwoven people, bots, topics, relays, clients, events, recommendations, lists, feeds, micro-apps, macro-apps, Chinese spam, and "GM"s.
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](https://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](https://github.com/nostr-protocol/nips/pull/218) (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](https://github.com/mikedilger/gossip), called "Gossip". This unfortunately created a lot of confusion, since [gossip protocols](https://en.wikipedia.org/wiki/Gossip_protocol) 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](https://github.com/nostr-protocol/nips/blob/master/65.md), 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](https://github.com/nostr-protocol/nips/pull/1171) 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](wss://purplepag.es) or [relay.nostr.band](wss://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](https://github.com/nostr-protocol/nips/blob/fade0164f52033314bf0a5ef9bd63c2483afae9b/10.md#marked-e-tags-preferred) 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](https://coracle.social/nevent1qythwumn8ghj76twvfhhstnwdaehgu3wwa5kuef0qyv8wumn8ghj7cm9d3kxzu3wdehhxarj9emkjmn99uq3samnwvaz7tmrwfjkzarj9ehx7um5wgh8w6twv5hsqgrn7l6zj7ht6ruyk76vvvtkfs4xrhyzc3tm64l3eyfvd40y26sz0gshmunh) to me by Mazin of [nostr.wine](https://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](https://habla.news/u/hodlbod@coracle.social/sfwV1rNaoQXd65PbIMYgm).
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](wss://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](https://github.com/nostr-protocol/nips/blob/master/17.md) requires users to publish a different relay list before they can receive direct messages, while [NIP 72](https://github.com/nostr-protocol/nips/blob/master/72.md) 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](https://github.com/nostr-protocol/nips/issues/1282), 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](https://github.com/nostr-protocol/nips/pull/230) 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](https://coracle.tools/) 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](https://www.youtube.com/live/Nz15SyiwQFk?t=2751s) last year. I also wrote up a [blog post](https://habla.news/u/hodlbod@coracle.social/1700155417145) 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](https://github.com/nostrability/nostrability/issues/69#issuecomment-2310524841), which includes some details about challenges I've faced putting Outbox into Coracle.
Wrote something up after seeing this: naddr1qvzqqqr4gupzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqq2nskt2w9vx6dznfdvj64rpw4mk5nmxf3v9xsd0gdy
Let me know if it suits the purpose, or whether it's too technical.
Thanks for the mention! Worth noting, Coracle also allows you to share feeds as nostr notes, as well as search and bookmark ones created by other people. It's rough right now, but I think really promising.
Just found the issue, it looks like bitcoin-connect is trying to download fonts. nostr:nprofile1qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qyfhwumn8ghj7ur4wfcxcetsv9njuetn9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcppemhxue69uhkummn9ekx7mp0qywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uq32amnwvaz7tmjv4kxz7fwdehhxarj9e3xwtcpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uq3vamnwvaz7tm9v3jkutnwdaehgu3wd3skuep0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz9rhwden5te0wfjkcctev93xcefwdaexwtcqypr90hlgjed73xq2jvrjhna4ukdx2yjyqmdslqvjzhh83wj8jd9nu66nryl nostr:nprofile1qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcppemhxue69uhkummn9ekx7mp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsz8thwden5te0dehhxarj9e3xjarrda5kuetj9eek7cmfv9kz7qg3waehxw309ahx7um5wgh8w6twv5hszymhwden5te0wp6hyurvv4cxzeewv4ej7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uq3jamnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kz7qghwaehxw309ashgmrpwvhxummnw3ezumrpdejz7qpqxv8mzscll8vvy5rsdw7dcqtd2j268a6yupr6gzqh86f2ulhy9kkqs7fv6h any way you can fix that for us?
Oddbean new post about login | logout
Notes by hodlbod | export
Nostr is a mess. It always has been and will always be. That's part of the appeal! But it's important that users be able to navigate the rolling seas of this highly partition-tolerant network of kaleidoscopically-interwoven people, bots, topics, relays, clients, events, recommendations, lists, feeds, micro-apps, macro-apps, Chinese spam, and "GM"s. 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](https://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](https://github.com/nostr-protocol/nips/pull/218) (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](https://github.com/mikedilger/gossip), called "Gossip". This unfortunately created a lot of confusion, since [gossip protocols](https://en.wikipedia.org/wiki/Gossip_protocol) 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](https://github.com/nostr-protocol/nips/blob/master/65.md), 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](https://github.com/nostr-protocol/nips/pull/1171) 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](wss://purplepag.es) or [relay.nostr.band](wss://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](https://github.com/nostr-protocol/nips/blob/fade0164f52033314bf0a5ef9bd63c2483afae9b/10.md#marked-e-tags-preferred) 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](https://coracle.social/nevent1qythwumn8ghj76twvfhhstnwdaehgu3wwa5kuef0qyv8wumn8ghj7cm9d3kxzu3wdehhxarj9emkjmn99uq3samnwvaz7tmrwfjkzarj9ehx7um5wgh8w6twv5hsqgrn7l6zj7ht6ruyk76vvvtkfs4xrhyzc3tm64l3eyfvd40y26sz0gshmunh) to me by Mazin of [nostr.wine](https://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](https://habla.news/u/hodlbod@coracle.social/sfwV1rNaoQXd65PbIMYgm). 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](wss://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](https://github.com/nostr-protocol/nips/blob/master/17.md) requires users to publish a different relay list before they can receive direct messages, while [NIP 72](https://github.com/nostr-protocol/nips/blob/master/72.md) 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](https://github.com/nostr-protocol/nips/issues/1282), 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](https://github.com/nostr-protocol/nips/pull/230) 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](https://coracle.tools/) 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](https://www.youtube.com/live/Nz15SyiwQFk?t=2751s) last year. I also wrote up a [blog post](https://habla.news/u/hodlbod@coracle.social/1700155417145) 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](https://github.com/nostrability/nostrability/issues/69#issuecomment-2310524841), which includes some details about challenges I've faced putting Outbox into Coracle.