Does the AT protocol support content signing? #1019
-
does the AT protocol support content signing? eg, will a user be able to create a digital signature for a piece of content that can make a strong proof of provenance, regardless of(independent of) where the content is hosted/posted? this, to me, seems like the increasingly needed next step in a world where soon anything can be faked by llms and ai agents. alternately, if this is not in the AT protocol, do people have ideas to either expand of extend or interact with AT to support this use case? thank you |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
Content in an account's repository is always signed, using the "atproto signing key" from the account's DID document. This key can change over time (key rotation), but the most recent version of the repo (the most recent commit) should always be signed by the currently valid signing key. This design, which is similar to signed commits/tags in git, is a classic use-case for Merkle trees, and was intentionally chosen over signing each piece of content individually. Signing each piece of content is much more resource intensive (of CPU, storage, and bandwidth), and makes key rotation much more expensive. Content outside of repositories, such as labels, may also be signed in the future. Each use of cryptography requires care and thought, so we are going slow and don't have a generic signing mechanism, and intentionally do not support encryption/decryption using the atproto signing key for now. |
Beta Was this translation helpful? Give feedback.
Content in an account's repository is always signed, using the "atproto signing key" from the account's DID document. This key can change over time (key rotation), but the most recent version of the repo (the most recent commit) should always be signed by the currently valid signing key.
This design, which is similar to signed commits/tags in git, is a classic use-case for Merkle trees, and was intentionally chosen over signing each piece of content individually. Signing each piece of content is much more resource intensive (of CPU, storage, and bandwidth), and makes key rotation much more expensive.
Content outside of repositories, such as labels, may also be signed in the future. Each u…