so, you don't want your app to decrypt the state of your account, ok
don't force that on everyone else
and don't assume that coracle's implementation isn't naive and doing work when it doesn't have to
i've quite kicked a hornet's nest here
good
because i know confidently how encryption works, i have been working with EC signatures and encryption algorithms for 8 years now
but don't bother asking me, of course, because you all know better
I don't want the app storing my data on public relays, regardless of the cryptographic nature. I'm arguing that the UX blows when decrypting DMs at startup.
If you want to ask me for a single decryption request when I load, that's better (ill personally decline it). But I also want the app to still function when I decline it because maybe I don't trust the app. It needs to be able to fall back to some type of local storage
Double checking here:
Let's say I have my own private relay (inbox). If I'm the only one being AUTH'ed on it, does the data it sends to a client need to be encrypted?
Or can it in theory receive encrypted messages, decrypt them, wait for me to open my chat app and send 'em over?
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.
