This is probably the best explanation of the issue with calling Primal a "client" that I have seen. Thank you!

If the app you are running on your device isn't reading directly from Nostr relays, it's probably fair to call it something else, rather than a Nostr client. Otherwise, it would be akin to calling something a Bitcoin node when it isn't downloading and validating blocks locally, but merely trusting the information sent to it from some outside source.

I think I like your idea of calling Primal's apps "Nostr gateways" instead of clients.

Reply to this note

Please Login to reply.

Discussion

Yeah, we discussed our architecture internally, at length, and decided to stick with NIP-01.

Both for transparency and simplicity, and so that anyone can host or fork our client, and add his own community relay, and have all core functionality immediately work and all the events from that relay immediately present. It also means that a user can log in and easily switch to using their own relay list for reads and writes, with a big toggle on the landing page. That way, even the person running the community relay can't stop them from reading and writing whatever they want, using our client.

And all communication is instantaneous, with no weird lag because of filtering, blacklisting, or the funnel effect of everything being pulled through one server. You aren't stuck using effectively one relay to read, and if one of the relays goes down, you won't even notice.

I feel like that's the Nostr "secret sauce", so abandoning this principle detracts from the usefulness of the protocol and undermines the censorship resistance of the original deisgn. I'm hopeful that Primal might actually implement that as an option, tho. We'll see.

The most recent update was definitely a step in the right direction. Time will tell.