Encryption for private content

[theefer]

The proposed architecture looks very promising for public discourse, but it doesn't seem to cover any notion of private discourse (e.g. equivalent to Twitter DMs or WhatsApp/Facebook groups). Do you have any ambition to cover such types of content/communication as well, and if so, do you have any preliminary designs for how it could be built on top of the ADX architecture?

If I understood correctly, the lower layer of the ADX design (identity & data, without the indexing/aggregation) doesn't look particularly specific to social media, other than managing a collection, mainly queryable in time order. This could make it a useful foundation for other types of information, and make ADX a potential alternative to other emerging portable personal data solutions like Solid or Textile Threads. However this would only be viable if users could control access to their data, presumably through some kind of end-to-end encryption architecture.

[ziiw]

New here

Could this be handle via a custom schema that would be describing encrypted content, made for private messaging between two DID?

[ianklatzco]

Yes.

[bnewbold]

We are definitely interested in non-public content! Including things like end-to-end encrypted DMs, groups, "private accounts", paid subscriber content, etc.

We currently don't think that simply plopping encrypted content in to public atproto repositories is a good idea. Having encrypted content broadly available and even archived really raises the stakes for key loss and content leaking. While there is nothing technically preventing it, and folks can build whatever lexicons and stuff whatever bytes in their own repos, we would discourage folks from building atproto services that store encrypted content in repos.

Our dev team has lots of ideas and is really excited to work on these features, but will not be focusing on this until after our core moderation and federation features are launched.

[proggeramlug]

Love it!

I would love for you guys to share more about these "ideas" and to potentially allow/encourage/work-with other developers to achieve this. Like, I personally, would love to get involved with some of these features.

[npetrangelo]

Any updates on that? What are the leading ideas?

[erlend-sh]

From yesterday’s roadmap post:

Private content and messaging (DMs): We intend to eventually incorporate group-private E2EE (end-to-end encryption) content in the protocol, as well as a robust E2EE messaging solution. These are important and rightfully expected features. We expect this to be a major additional component of atproto, not a simple bolt-on to the current public repository data structure, even if we adopt an existing standard like MLS, Matrix, or the Signal protocol. As a result, this will be a large body of integration work, and will not be a focus until after federation.

I think the clear top candidate here is MLS, as an emerging internet standard for encrypted messaging interoperability: https://messaginglayersecurity.rocks/

It’s already far along the IETF standardization track that atproto aspires to enter.

Matrix is hard at work to become fully compatible (in many ways even merge) with MLS: https://arewemlsyet.com/

[bnewbold]

MLS looks promising as a low-level technology, and linearized Matrix running on top of that could be a possibility for DMs and group chat. The path to broad interoperability with external group-chat systems (like WhatsApp, Telegram, etc) seems like it might be a ways off (years?), efforts like MIMI are still being developed. The pressure of EU regulation on this front does seem effective and there is a lot of inertia towards interoperability in this area.

[cabra-lat]

I hope not being that-person-that-bumps-dead-threads-in-discussion-foruns but here we go.

I was wondering about how to address the privacy concerns (since everything is public so far).

I've been experimenting with a key wrapping mechanism, using gpg and since then, I've been trying to figure how this approach would work in the ATproto context. And I've came up with some scenarios (I swear I wrote this myself):

Option A: create a random key for every new content

• For every private content, encrypt it with a random Data Encryption Key (DEK).
• Then, for every person I want have access to the content I encrypt the DEK using my private key and their public key

Consuming a private content:

• The person receives something in the feed which have private contents, check if it has access.
• The person decrypts their key (finding the DEK) and finally can decrypt the post.
• If not the front-end just ignores the content.

Revoking access:

• The person re-encrypts all prior contents with new random DEKs and encrypt them for every current DIDs with a access to your content.

Pros:

• Avoids a actor with access to share their DEK with third parties, granting access all at once.
• More control over which content you grant access to what person.

Cons:

• It may have a higher cost.
• Won't stop a malicious actor to gather all DEKs from all your posts (but you can't avoid the sharing by other means, say screenshots or manual scrapping, anyway).

Option B: a single DEK for each DID

• Same thing, except now each DID will have a single DEK which should be encrypted asymmetrically for every other DID you want to grant access.

Consuming a private content:

• Same thing.

Revoking access:

• Just change the DEK, re-encrypt all posts with it and encrypt asymmetrically the DEK for each DIDs you want to grant access.

Pros:

• Way more simple to implement.

Cons:

• A single DID can disclose with third parties all the future and past data for a given account by decrypting their DEK.
• Less fine grained control over who access what.
• A new permit will disclose all past contents to that person.

Option C: why not both?

• For accounts that want a fine grained control let them go with A
• For accounts that want less control let them go with B

I guess this way we could use the already existing private key and encryption methods to restrict access in some extent.

[Ai-rin]

Speaking of messaging, have you considered the possibility of creating an atproto-based alternative to matrix/discord chatrooms?

[apatrida]

Just change the DEK, re-encrypt all posts with it and encrypt asymmetrically the DEK for each DIDs you want to grant access.

If you already allowed access to content in the past, why revoke that. You can rotate keys moving forward for current allowed consumers and previous people can be prevented from reading the feed again from the PDS, but no need to re-encrypt. "The cat is already out of the bag" is reasonable viewpoint, as you really cannot control what content is copied/stored elsewhere in the universe, so just limit new reads and rotate keys for new content.

[ebwinters]

we will most likely have limited-visibility content simply not live in the account repos. For example, that content could be stored in the author's PDS, and authorized clients would fetch it from there

Can someone help explain the difference between these two? Since the PDS manages the repo, where else would data like mutes be stored other than the user's repo?

[Tamschi]

we will most likely have limited-visibility content simply not live in the account repos. For example, that content could be stored in the author's PDS, and authorized clients would fetch it from there

Can someone help explain the difference between these two? Since the PDS manages the repo, where else would data like mutes be stored other than the user's repo?

The (public) "repo" broadcasts any changes across the firehose, it's only for public records like blocks.

There's an additional (similar?) private storage area for each user (in the PDS, I believe?), which is afaik where mutes are stored, but I haven't seen much documentation on this at all. I'm not sure it's currently officially open to third party apps.

[ebwinters]

mutes are stored in the app view, which is a Bluesky specific DB.
My question is to clarify "limited-visibility content will not live in repos but in the PDS", since repos are where content is stored in the PDS. Is the idea there will be a secondary DB in the PDS?