Nostr Web Client

I think this is where nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s was getting confused. I’m not suggesting the outbox model that adds relays to your list of relays… your list of relays remain static.

I’m saying to only leverage the outbox model when there are missing notes your list of relays don’t have, that way you are reaching out to the potentially evil relays with a note hash — if the note matching that hash isn’t delivered, then the evil relay can’t do anything but get your IP.

This is more of a hybrid approach…

Read from relays you write to —> clients can store data like relays and sync missing notes with a secondary list of relays using negentropy (snort coded negentropy in typescript already) —> gossip model for fetching missing notes if the first two methods fail.

This seems like a solid plan/layers of redundancy for discovering missing notes…

Thoughts? nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

Phi Am I 1y ago

Hhhmm, I'm going to go have a think about a way to exploit this model.

Oh the other hand, is note retrieval across relays a problem serious enough to warrant additional automated discovery of relays? A new user with a fresh client is going to have way more trouble than a long time user with a well curated list of relays. How often does a long time user have problems retrieving notes?

I'm not a fan of relays that bridge nostr to mastodon. I don't ever want mastodon posts filling my feed. What happens when the note that can't be retrieved wasn't actually a nostr note, but a bot created cross post from mastodon that I don't actually want to see, by not including bridge relays in my client?

Reply to this note

Discussion