1. Network effects are baked-in. Devs don't like to sell/advertise. It's nice when you can just create something and use an efficient social design to let word-of-mouth do its thing without relying on a controlling party, like an app store. It's also incredibly rewarding.
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.
3. Login is solved. Devs generally start any app with the Account Management part, designing screens, o-auth backend, password recovery, 2-step auth and so on. It takes a lot of effort to get to the point where you can actually build the app you want to build.
4. Social First. Every app is a social app. But devs usually build things first and then add a social "feature" into it. That doesn't work. With Nostr, you are forced to start with the social component and build what you want to build on top of it. And devs see that as an extra positive feedback loop for the community.
5. Do whatever you want. It's shocking how open Nostr's data models are to any type of application. Just pick a number, sign, and go. Make a NIP if you want to interoperate with others.
> 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.
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.
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.
Thread collapsed
Thread collapsed
Thread collapsed
