Re: [damus-io/notedeck] Relays architecture (Issue #100)

[William Casarin]

@KernelKind wrote (from [#100]):
> How will the relay architecture be implemented? Will each user account
> (public key) have a relay list associated with it? And the current
> deck will use the relay list associated with the current user account?
>
> Related to [#81]

There should only ever be a single relay connection manager. When
switching accounts, the relay pool simply maintains connections to all
of the relays shared between these accounts.

I removed the RelayPool from the UserAccount because it doesn't make
sense there. There should only ever been one connection pool, otherwise
there would be multiple duplicate connections.

Keypairs have lots of associated data: mutelists, relay lists, deck
lists, etc. It doesn't make sense to store those in UserAccount (aka
Keypair). We can simply look those up in nostrdb when we need them, as
we would want to make sure we are always in sync with whatever the
latest version of those notes are.

We do this with profiles, which requires us to build a flatbuffer schema
in nostrdb which can be a bit of work, but it simplifies notedeck code
greatly when we do this. Profiles are the main example right now of
something that parses json and stores it as flatbuffers in nostrdb.

It might make sense to add some more flexible machinery to nostrdb that
allows you to parse arbitrary json data and store that as flatbuffers,
but that would require some metaprogramming so it might be tricky. The
alternative is messagepack which is a bit slower but more flexible for
parsed data at runtime.

Another thing to mention from the refactor[1]: the relay generator also
didn't really make sense. For example, in the outbox model, relays are
selected dynamically from other user's relay lists. It is not as simple
as selecting a single pool and then using that.

Outbox model relay selection is a function of the type of query you're
doing. For example, if pulling a user's profile page, you likely just
want to exclusively pull from that user's set of relays they write to.
In the timeline case, we have to do this but as a union of all the
pubkeys on your contact list, with some algorithm to choose a subset of
all of those user's relays to query from. In threads, we follow relay
hints, etc.

These are all ephemeral outbox connections. We can have some kind of LRU
connection pool for outbox connections if we want to limit the number
them.

[1] https://github.com/damus-io/notedeck/pull/80/commits/31b2b5c950591536263f3218bf4a11e8f6b59ec1
[#100] https://github.com/damus-io/notedeck/issues/100
[#81] https://github.com/damus-io/notedeck/issues/81