What do you propose calling the approach instead?
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.
Discussion
It may be useful to have a comprehensive site or in-client feedback on how well various clients and profiles support this approach? Might help move progress forward.
It would be good indeed, one could start by reading the code and asking the developers questions about how it works, then testing edge cases on each client.
