i know you are a bit excited about this but after you think it all through for a while, digest it, you will have some good insights

i think that nip-86 was not really quite the right direction to go with this issue, it really needs a bigger plan than just addressing the superficial requirements, because of the threats that could be involved

for sure, limiting risk can be easily achieved by only having one owner who has superseding rights and technical skill to detect and remedy problems

the more people you give administrative rights, the less powerful administrative rights have to be

Reply to this note

Please Login to reply.

Discussion

Ideally, even a person who can leak the decrypted data wouldn't be able to make sense of that data.

Like, if you used multisig. 🤔

Or batch discovery. Hmm. The server holds the key, maybe, and three people hold the server key.

this is a painful rabbithole you are diving into there

we have to define our threat model, and you must not think outside of it for reasons you are experiencing

we have to trust our server's physical security, for example, or otherwise we have to have physical hardening on our servers, which is a great increase in cost

it can be mitigated by making encryption schemes that defeat physical breaches, but there is limits to how strong you can make this security, especially with scale, cryptography gets astronomically expensive at scale, the math is absurdly expensive compared to simple ordinary computations, the overflows and so forth involved tend to be in the dozens if not hundreds of cycles per operation

Yeah, that's why we want different machines. Then you move the threaten more internal, which is easy to manage with permissions.

LOL you know how much I love this logic stuff.

you have work to do i seem to recall, stoppit

Okay okay.

Just realized that you could brute-force list discovery by just trying to AUTH with any active npub.

yes, "privacy protected" means that every user is an entry point