Nostr Web Client

Where can I follow the discussion around relay gossiping? #[0] recently mentioned that people have been talking about it, but nothing is set in stone.

Clearly the protocol wraps around the idea that messages themselves can recommend relays. e.g. a user profile contains their relay list & any event can include recommended relays when referencing other events and pubkeys.

My naive initial thought is that clients should

connect to a set of relays that give access to all the pubkeys you follow + all the relays you define as your own

when they see a new kind 0 profile clients should republish this to all the relays they are connected to (thereby propagating profiles eagerly)

Something like.

* Your profile's relay set {A, B, C}

* You follow alice, who has a relay set of {A, F, H}

* You also follow bob , who has a relay set of {E, F, G}

* At runtime, a client connects to {A, B, C, F} because you should always connect to your own set, plus you need to connect to something that knows about bob's events. We choose F because it's weighted higher for us, because alice also publishes there and we can get more redundancy.

When we see bob update their profile, we republish the new profile to every relay we're connected to so that more people know how to find bob. He would have written to {E, F, G} but with our help his profile is also in {A, B, C}

fiatjaf 2y ago

You may have heard about "the gossip model" which has this horribly confusing name because of the client called Gossip at https://github.com/mikedilger/gossip -- which has nothing to do with actual gossiping. It should be called the "outbox model", that would be a better name.

But take a look at NIP-65. The basic idea is that you can find the relays someone announces they're publishing to and you can read their notes -- and their notes only -- from there. See also the Nostrovia podcast episode with Mike Dilger, https://mikedilger.com/gossip-relay-model.mp4 and https://fiatjaf.com/3f106d31.html

Reply to this note

Please Login to reply.

Discussion

n 2y ago

基本的な考え方は、誰かが発表しているリレーを見つけることができ、そこから彼らのノート、そして彼らのノートだけを読むことができるというものです。

ゴシップモデル」という言葉を聞いたことがあるかもしれませんが、これは「Gossip at https://github.com/mikedilger/gossip」というクライアントのせいで、ひどく紛らわしい名前になっています。実際のゴシップとは全く関係がありません。

#[2]

Blake 2y ago

#[3] I had an issue yesterday in gossip with the model, as it picked two main relays (each with 90% of my followers) - the second catch was one of those relays kept disconnecting and was unstable. That means I was left with one relay for 90%.

I know there is a setting for “min N relays per pubkey up to max of M relays”. It wasn’t working. Maybe as using master.. but it’s an edge case that the model needs to allow for - unstable relays. Maybe the gossip client supports it or partially… but didn’t seem to be working.

Jem 2y ago

Yes, given varying performance levels for relays it should probably assign each relay a weight. (Haven’t read the links yet, just woke up)

Blake 2y ago

It’s deceptively complex to do it optimally - but good enough works ok too. Which relays you receive from differs, even by kinds you want, and publishing is similar complex.

Not sure if helpful, but a dump of my notes below around relay selection. Trying to end up with a diagram and list of functions that explain what logic to apply when and how to pick and prioritise relays.

Paid relays, rate limiting, kind, destination pubkeys, your preferences, relay hints, proof of work, parent events, mentioned pubkeys, etc — all can factor in. Relay health/connectivity.

——

getBestOutboundRelayForEvent

(Note: A paid relay filter should apply unless you have paid)

Kind 0/3/10_002

Maximally broadcast

Publish to Metadata Indexer Relays

Note (without reply or mention)

Do you want to maximally target your followers?

Do you want to maximally broadcast?

Reaction

Include parent relay hints (if provided)

getBestOutboundRelayForPubkey(author)

Repost

Include parent relay hints (if provided)

getBestOutboundRelayForPubkey(author)

Do you want to maximally target your followers?

Do you want to maximally broadcast?

Include parent relay hints (if provided)

getBestOutboundRelayForPubkey(author)

Do you want to maximally target your followers?

Do you want to maximally broadcast?

Reply + Mention

Include parent relay hints (if provided)

getBestOutboundRelayForPubkey(mention) for each mention

Mention

getBestOutboundRelayForPubkey(mention) for each mention

getBestOutboundRelayForPubkey(recipient)

Event Report

? Broadcast or targeted relays ?

Long form Content

? Broadcast or targeted relays

(Nostr-connect)

(Zap Service Provider)

getBestOutboundRelayForPubkey

Kind 10_002

NIP05

Kind3 (or EOL?)

Fallback to my Publish/Write relays (as they can query them for lookup)

----------------------------

getBestQueryRelayForPubkey

getBestQueryRelayForEvent Id

If only an event Id is known.. Shotgun query / your read relays

getBestQueryRelayForEvent

Include event relay hints (if provided)

Check parent event (if known) relay hints

getBestQueryRelayForPubkey for each known thread participant

Other considerations

Min POW Required

Rate Limiting

Jem 2y ago

This is a super interesting problem

Blake 2y ago

Yep. The gossip model was effectively my initial approach too, for an unreleased relay recommendation engine, before I realised it was more complex. My approach was data driven, so basically which relays saw a pubkey’s 200 most recent events, rather than based on the kind 10002 pubkey relay manifest approach.

Basically similar to what you mentioned above, with a N coverage threshold and M max desired relays.

https://en.wikipedia.org/wiki/Set_cover_problem

あすらも / heguro 2y ago

これですね、存じませんでした。情報助かります！

#[2]