Subnostr

> 2. Database is solved. Users will choose their relays. You don't need to put anything up. There is no need to spend hours specing out your database tables, mapping them into objects, and then making all the data access layers. No liabilities, no operational costs, no risks, and, more importantly, no long-term commitment to secure and keep the data available to your users.

It's bizarre how this implementation detail occupies the mind of nostr "architects" out there. Clients should cache things (and are in the case of local relay) but in the end that's an implementation detail. Client, cache, local relay, relay are all just terms for "peers" and any peer should be able to talk to any other peer.

Yes even relays should talk to one another and already are in the case of "boostr". Aren't they.

Your idiosyncratic terminology isn't helping things.

Vitor Pamplona 1y ago

That's a typical corporate dev mindset.

Many things in Nostr can be generalized in the same way you are generalizing with "peers" but you are loosing information when you do so and it is terrible for the growth of Nostr. It makes things unecessarily complicated because a "peer" can do a lot more things than a "relay" or a "client". Keeping people focused is helpful.

Reply to this note

Please Login to reply.

Discussion

frphank 1y ago

No because the outbox discussion has shown that the whole architecture of nostr yet has to be solved and balkanization of peer roles and terminology is an obstacle.