Look, I'm trying not to embarrass you, but it's clear you don't know what you're talking about. It's not 2000 anymore; servers have immutable, verifyable runtimes that can't be hacked the way you are talking about. It is possible, just not common practice, to provide full attestation of server code so that users can verify (byte by byte) that build A is running in immutable container B. note156x0nyw5wlthztyne4uaekvffu9hhmh7lhl5u3yskkvksvkavhxsmvp48h

Primal clients read from the caching service and write directly to the user’s relays. We chose a set of tradeoffs based on what we are trying to accomplish: best UX possible. We’ve been very transparent about it from Day 1. See my blog post from March 13, 2023 - the day we launched Primal. I still think that caching services are not only great for UX, but also a legitimate way to help scale Nostr once we hit millions of users. They could even improve censorship resistance, since anyone can stand them up and create more copies of Nostr events. Having said all that, the Primal stack is evolving and becoming more capable on the client as well. One can imagine peer-to-peer transfers between clients that have client-side databases, like Primal for Android. I think Nostr will have it all: relays, indexers, caching services, client p2p transfers. It will be very hard to stop. Claiming that there is only one way to properly build Nostr clients and that everyone must choose exactly the same set of tradeoffs is silly. For example, gossip/outbox purists might take issue with how Damus works. Everything we build at Primal is open sourced under the most permissive MIT license. I believe we offer the only open source indexer for Nostr (someone please correct me if I’m wrong). Anyone can stand up and run their own caching instance. Other projects have done so in the past. Primal users hold their keys and can move to another client at any time if they don’t like how our product evolves. On a personal note Will, you constantly fud Primal. You tried to cancel us before, joining semisol’s cEnSoRsHiP nonsense campaign. Your latest initiative - trying to impose rules on what can be called a Nostr client - is also an attempt at cancelling. I don’t know what to make of it because you are always very friendly in person. We spent a considerable amount of time together, and you never raised these issues with me face-to-face. Why not? On the contrary, you always seem to have kind words for Primal when we talk. I’ve never said a bad word about Damus or any other project. I want to be on good terms with all Nostr builders, but you are making it hard with posts like this.

If the primal client isnt ALSO writing to the caching relays this will continually lead to people's replaceables (follows, lists, etc) inadvertently wiping out what the user wants it to be. Your caching service is NOT UPDATING at an appropriate pace for this flow model

Dear @miljan about friendship I, on the other hand, would like to understand why you gave me the nip-05 isolabellart@primal.net and direct link

🟠 isolabellart

I paint in oil.
Inspired by time, silence, and light.
Each work is unique and for sale in Bitcoin.
→ 
Paintings notes: #isolabell...

and now you tell me that being an early adopter I will get it for free only until June 2025 and then I will have to pay. In my house gifts are not paid for. Have a nice day 🫂🎨

👆I knew I was right about Primal. I’m a Damus maxi. Always will be. Damus goes south, I go south. Literally. I’m thinking of moving south at some point.

Hi. Conveying important ideas to many people can be more difficult than it seems and there is a high risk of not being understood or putting the emphasis wrong. Put your ego aside and try to think about the common users and values, if you want to build something big or convey your concerns. Otherwise, everything will be as before, and is it worth starting then.

Can you write docs for the caching service?

> The hack risk of your client trusting zap addresses from a trusted backend is too high, money could be sent to the wrong place, this would tank nostr’s credibility. This is an argument against zaps. They add nothing but unnecessary risk.

How can you be tryi g for the best UX when you don't have amber login?

I thought the zap addreses where stored in a local cache. having it in the backend would be innecessesarily wrong, I give you that. Their should be different sources of indexers and should have a Merkel root that contains all events that attestate for each post so u could audit it.