Clients and relays do not use any form of data encryption (defined in the nips) to speak with each-other, only TLS, TOR, and so on. This encryption is strictly for client data.
Are you suggesting storing plaintext client data, in a private relay, so that it could avoid that UX hassle?
I would love for clients to have that fine grained control over relays. Personally I'm mad and I'd like for every note signed, the option to select which relay it gets sent too.
Yes, that's what I'm suggesting indeed.
The incentive for users to have their own relay is already huge, even without this.
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.
> the option to select which relay it gets sent too
Yup, I've been breaking my non-dev mind over where to propose this crucial feature in the NIPs.
Needs:
1️⃣ Npub can specify what relays an event is targeted at
2️⃣ Npub can edit this relay-set later on
An h-tag with the target relay, such as Chachi and the NIP-29 complexity lovers use, can only do the trick if the tags are editable after the fact.
NIP-70 does this in the best possible way.
With this, how does the author say "this event is targeted at these relays"?
This NIP asks relays to reject events with a ["-"]. It doesn't help in specifying the target audience for the event. That's what I need. In a way that's editable. For any event type.
