How can web apps be independent protocol clients?

Nostr is a protocol designed to work with fully independent clients. Each client is meant to talk to multiple standalone servers and act, like a web browser, as a true "user agent", requesting content that the user wants to read and signing content that the user wants to publish. A fundamental assumption of Nostr is that servers are free to be as evil as they want as long as clients are working to serve the interests of users.

This works relatively well with native clients assuming the user knows what it is installing and running and client has a name and a reputation (even in the world of mobile "app stores", as bad as it is, the assumptions still hold somewhat as updates are optional, relatively rare and discernible, and they're the same for everybody). Once a user installs an app it is in a way "theirs", it is running in their computer and doesn't depend on anyone else to keep running.

The same can't be said about "web" clients as they necessarily rely on a DNS domain name and a server owned by someone else, so a web client can't ever be trusted as an installed client can. They can't be fully user agents as they'll always remain (at least a little bit) agents of their true owner, the person who has the domain name.

An example

Everything is fine with, say, https://jumble.social/, until npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl decides to shut it down and its users lose access to their client; or maybe he is threatened to include some malicious code in there, most Jumble users are going to fall for that and Nostr will feel broken; finally even a small harmless change in the way it does some specific thing can be bad as it's impossible to opt out of.

Subjective apps

Maybe the correct way to approach this would be to treat "Jumble" as a subjective concept of an app. Not "whatever is on the jumble.social domain", but "this version of Jumble I use (represented by this hash), this is what Jumble is to me".

Any real Nostr web client must be capable of running entirely on the client side, as a "static" webpage made of just HTML, JS and CSS, so it should be possible to have these files hosted on Blossom and referenced by the hash of the "index.html" or something like that.

The hard part is how to get users to use not https://jumble.social/ directly, but their chosen version of Jumble, which they may update voluntarily whenever npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl decides to publishes a new release (while also being able to opt out of the update), but which they also may decide to represent some other version (hash) branch of Jumble, published or maintained by someone else.

It gets more interesting when subjective changes to the concept of "Jumble" (i.e. ignoring the original author and assigning that name to a contentious fork, for example) get propagated through the friends and friends of friends of the people making the switch, such that others can learn that there is a new Jumble in the town and opt to switch too, or maybe use both, give them different names and so on.

A lazier solution

To me the idea described above sounds very good, but I'm not super hopeful it can be accomplished soon given how weird it is. There is another, perhaps easier, but also less elegant solution, that may end up being adopted: that is for users to learn that Nostr clients, even web clients, aren't a single thing, they are many, and the same user may learn that they're able to use different clients simultaneously, and easily switch their habits from one to another.

If users have this conscience it may be that they won't find it hard to switch from jumble.social to fevela.me when they learn that the first is doing something they disagree with. They may also be using yakihonne.com or coracle.social as secondary clients in parallel, so even if jumble.social shuts down entirely they won't be left hanging and will be able to use these secondary clients to learn of all the Jumble forks that may have appeared in the meantime that they can try.