3 ms·

It's an unsolved problem as I understand it. Key distribution, rotation, and revocation in e2e have no good options that also provide a competitive UX. This is

by verdverm 10mo ago

It's an unsolved problem as I understand it. Key distribution, rotation, and revocation in e2e have no good options that also provide a competitive UX. This is why you don't see it more ubiquitously. What you do see is individual data handled more this way. A different approach would to not give individuals decryption keys for the data directly, rather give them access to a shared key JIT. This is how we generally operate with secrets in the cloud, and this would be doing the same to get access to the secret decryption key, preferably in a locked down env they do not control and have little permissions in, if even a human at all

allen-chen 10mo ago
Agreed — UX vs. revocation seems to be the core blocker. The JIT/shared-key approach makes revocation much cleaner, but it also shifts trust to a controlled environment rather than purely client-held keys. Have you seen this used beyond secrets (for large file sets), especially where offline access or long-lived clients are involved?
- verdverm 10mo ago
  I'm actively working on something like this for/with ATProto PDS, mainly for permissions, unencrypted, but the next step e2e hit me up if you want to chat, same handle everywhere and at gmail
  - allen-chen 10mo ago
    That’s interesting — especially if you’re already thinking about the e2e step on top of ATProto PDS. At the permissions layer, I’m curious how much of that design you expect to carry over once decryption keys are involved. Happy to follow up off-thread as well.
    - verdverm 10mo ago
      I am not aiming for something as e2e as you, because it has unsolved problems and I want to build an app with private data features today For what I'm doing, everything should carry over because the permission system doesn't care what data it is gating The hard problem I'm working on now is content moving or gardening in the face of at-uri. Users want to be able to drag-n-drop things, i.e. move a doc from one folder to another to share with a lawyer (Google docs inspired) Have you seen peergos? It's spiritually closer to what you are after, iiuyc
      - allen-chen 10mo ago
        Makes senses — shipping “private data” features today without full end-to-end encryption is a reasonable constraint tradeoff. I’ll take a look at Peergos — appreciate the pointer.

allen-chen 10mo ago

Agreed — UX vs. revocation seems to be the core blocker. The JIT/shared-key approach makes revocation much cleaner, but it also shifts trust to a controlled environment rather than purely client-held keys. Have you seen this used beyond secrets (for large file sets), especially where offline access or long-lived clients are involved?

verdverm 10mo ago
I'm actively working on something like this for/with ATProto PDS, mainly for permissions, unencrypted, but the next step e2e hit me up if you want to chat, same handle everywhere and at gmail
- allen-chen 10mo ago
  That’s interesting — especially if you’re already thinking about the e2e step on top of ATProto PDS. At the permissions layer, I’m curious how much of that design you expect to carry over once decryption keys are involved. Happy to follow up off-thread as well.
  - verdverm 10mo ago
    I am not aiming for something as e2e as you, because it has unsolved problems and I want to build an app with private data features today For what I'm doing, everything should carry over because the permission system doesn't care what data it is gating The hard problem I'm working on now is content moving or gardening in the face of at-uri. Users want to be able to drag-n-drop things, i.e. move a doc from one folder to another to share with a lawyer (Google docs inspired) Have you seen peergos? It's spiritually closer to what you are after, iiuyc
    - allen-chen 10mo ago
      Makes senses — shipping “private data” features today without full end-to-end encryption is a reasonable constraint tradeoff. I’ll take a look at Peergos — appreciate the pointer.