By obfuscating relays, you encouraged users to think they don't matter, when they're actually an essential part of the architecture.

They should have pride of place, in your client.

#RelayCentricDesign

Reply to this note

Please Login to reply.

Discussion

I need to figure out the outbox model and use it. Not sure where to start

In principle, it's pretty simple. Each user reads from some relays and writes to others.

If User A wants to read an event from User B, User A should query the relays User B writes to, i.e., his outbox relays.

Likewise, if A wants to ensure B can see a note, A should send to the relays B reads from, i.e., his inbox relays.

How do you identify a user's inboxes and outboxes? There are a few ways:

- Query some common relays and download the user's relay list event.

- Use relay hints in events or event addresses themselves, as detailed by the protocol.

- Keep track of which event authors show up on which relays, and maintain a running list in-app of inboxes and outboxes.

Other methods are likely possible. The first two are the most straightforward; any client dev can start with those.

Is there a reason I don't want to just connect to every relay I learn of?

data use

And it slows the client down.

Everyone will have a personal relay, spread across all of their (online and offline devices) and they will use peer-to-peer strategies when they can. And it will be glorious.

I cannot put into words how much I agree with this statement. Obfuscating relays leads to nowhere good. The whole point of nostr is you control your identity. What good is that if you're not aware of how or where your data is stored.

nostr:nevent1qvzqqqqqqypzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqqsryj0kn7ps8qz560jx8ews5px0y5dfeqcmzpud9mxuuzjmh44qjmcf3xyx3