Yes, that's what I'm suggesting indeed.
The incentive for users to have their own relay is already huge, even without this.
Discussion
Hmm. I guess I would be inclined to avoid calling it a relay, because it has a very special purpose. You're basically looking to standardize a personal database api.
You'd probably want a way for the client to challenge the server (relay) before trusting it, which we don't have a spec for either.
We'd also want those relays to be local only, so that unencrypted data isn't sitting in plaintext on anyone databases.
I don't want my private relay (or server, indeed) to do only that specific thing though.
Neither do I want to set up fifteen different private relays, each with their specific purpose.
I want my server to challenge the buggy clients, lol 😂 .
Were just describing things like firebase lol. There are specs for http based abstract databases. It could be a standard. Call me lazy, but I'd rather client developers build this type of caching on their own, because if it's a standard its probably going to suck.
I've developed a framework for this exact purpose for my own apps
it just lets web client's store arbitrary data with a standard http endpoint. It can be protected by authentication and other stuff. Thats how all my apps store user's preferences. In Nvault I use to store all sorts of client-side data for every user. I use it for website whitelists, permissions, and so on.