OUTBOX MODEL

Motivation:

We don't all use the same relays. And from time to time we change which relays we use. In order to read the notes written by somebody, your client needs to find them. The outbox model is a straightforward way to do this.

Two types of relays:

In the outbox model, there are two kinds of relays: 'write' (or outbox) and 'read' (or inbox).

Write relays (outboxes):

Write relays (or outboxes) solve 90% of the problem as follows:

* When you create a note, write it to your outbox relays.

* When you want to read someone else's notes, read them from their outbox relays.

Read relays (inboxes):

If somebody tags you on a note, or sends you a DM, then the above won't work. Because maybe you don't follow them so you never read any of their notes from their outbox relays.

Read relays (of inboxes) solve this last 10% of the problem as follows:

* When you tag somebody in a note (including DMs), also write the note onto their read relays.

* Subscribe to your read relays for notes tagging you.

Relay lists:

In order for this scheme to work, people need to be able to lookup which relays another person uses. NIP-65 describes a kind-10002 event that people can use to publish which relays they use. These are suggested to be published to many relays so they can be found more easily.

How many relays?:

Some people have many outboxes. It is not necessary to read their notes from all of their outboxes. You only need to read them from one if that one relay is working and has all of their notes as it should. For redundancy and to be sure you aren't missing notes, you can choose instead to read from two of their outboxes. You could go higher, but for little additional benefit.

Following many people:

In order to follow many people, you may want to construct an algorithm tnat computes the smallest set of relays that covers everybody you follow twice (if you want two per person).

The gossip-relay-picker has an algorithm, but it is unlikely to be optimal and it remains an issue of research to come up with a better one.

When you do connect to these relays, it is important not to subscribe to everybody on every relay, but only to create the subscriptions you need in order to get one or two relays per person you follow.

Dealing with users who have not published a kind-10002 relay list:

Many clients do not support NIP-65. For users who have not published a relay list, there are a number of ways you can use to try to determine where they post. These include:

* The NIP-05 nostr.json file may contains relays for a user.

* An 'nprofile' object contains relays for a user

* kind-3 Contact List contents sometimes contain relay information (Astral and Damus did this, as well as probably some other clients)

* An 'nevent' contains relays, and the event itself has an author, which can be associated.

* Some tags have a 'recommended_relay_url' which associate a note with a relay. That note's author can then be associated to that relay.

* Clients can give users the ability to manually associate relays with people.

When a client encounters any of the data above, it should make an association between the user and the relay and remember how it learned that association, and perhaps also when it learned that assocation. That data is important for scoring the relevance of the association when determining what are the best relays to use for the person.

Then the best relays for a person can be chosen by an algorithm that sorts through those associations.