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.

[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.

[bnewbold]

We haven't finalized our plans yet, but 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. Or authors could have entire private repos, one for each "channel" or "group" that they correspond with, and have those repos only accessible to accounts on the ACL. There is no need for private data to go out over the firehose, be re-distributed by the Relay, etc.

[cabra-lat]

Interesting! I guess this is somewhat similar to how DMs are implemented.

Without going to firehose and relays, how the consuming side would reach the private content?
Would that require a separate feed or will the consumer need to actively seek it?

Looking forward to see!

[Ai-rin]

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