Nuh 🔻 on Nostr: I submit to you that "the rest is your imagination" (may the odds be with you) is a ...

I submit to you that "the rest is your imagination" (may the odds be with you) is a step backwards from the current web, where we expect URLs to be resolved in few milliseconds from cold start.

The reason I expect more from public keys, is because I know we can do better, and you don't have to take my word for it. You can just try it yourself, Now.

quoting note1qqq…hlgh

nevent1q…9z9u

The "outbox model" is kind of a misnomer actually, it can't be "implemented", it is just an idea.

The idea is: you have to organize your client in a way that it learns using all the information available where each pubkey is publishing their stuff to, then connect to those relays to fetch their stuff. That's it, the rest is your imagination.

The common tools that can be used for this are:
- kind:10002 relay lists
- relay hints in "p" tags
- relay hints in other tags
- relay hints in nprofile, nevent codes
- relays listed on nip05 /.well-known/nostr.json
- history of successes and failures when fetching events for a specific pubkey in a specific relay

I tried to convey the idea here: https://how-nostr-works.pages.dev/#/outbox (notice the table with a dynamic ranking of relays for a specific pubkey on the right). This is just an example of one possible implementation. It follows roughly what is implemented on https://pkg.go.dev/github.com/nbd-wtf/go-nostr/sdk/hints and is heavily inspired by some past version of https://github.com/mikedilger/gossip.