Who verifies the sign of repos? #1237
-
|
The signature included in the commit is not related to a general Bluesky client. Who is going to verify this and what to prevent? One of the usage I think is that Appview notices when BGS creates a fake commit. However, BGS is just one of the components that users depend on in atproto. I want to know what other useful usage is. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
|
Of course anyone is capable of verifying the signature on a repo. Defensive clients may opt to do so for instance. Generally, self-certifying data makes it such that you can trust data coming from a non-authoritative source. This allows an AppView or a Feed Generator to trust data from BGS (or elsewhere) even if they're not accessing it directly from the user's home PDS. |
Beta Was this translation helpful? Give feedback.
-
|
Should a defensive bsky client verifying an feed get MST and signature for each post? |
Beta Was this translation helpful? Give feedback.
-
|
Sure! Makes sense. Maybe another way to phrase @yamarten's question is, does ATP itself specify any specific times or places where signatures should/must be verified? |
Beta Was this translation helpful? Give feedback.
-
|
One current example is that the BGS specifically must validate signatures when crawling repos from PDS instances. Signature validation will probably also be mandatory as part of account migrations between PDS hosts. As a general principle, when receiving content from another organization or party it is probably a good idea: an ACME Club AppView consuming from an ACME Club BGS might not bother re-verifying signatures (but maybe they should!). |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's exactly what I wanted to know. |
Beta Was this translation helpful? Give feedback.
-
|
Two big goals with atproto repos are to make migration between PDS easy, and to allow flexible re-distribution of content from multiple sources. At a philosophical level, repo content is "self-authenticating": the authority comes from keys and signatures and the content itself, not which server it came from. Some examples of the value of re-distribution are that if the home PDS is down, content can be served from BGS or AppView. This is, in fact, the default for most readers, which also means that the traffic load on PDS instances is small. It is always possible to go back to the home PDS to get updated ("authoritatively current") repo content, but it isn't the only way to get it. There are contexts where validation is expensive and it is easier to just trust the source of the content. For example, fetching timeline feeds does not include the full "proof chain" for each post and reply, those would need to be fetched in follow-up calls for full validation. Also, things like "like" and "follower" counts would require fetching many proof chains to verify, and it is not possible to "verify" the non-existence of records from any repo. So there is some trust necessary for those to be quick and easy API calls (aka, to not have a full snapshot of the entire graph available). |
Beta Was this translation helpful? Give feedback.
One current example is that the BGS specifically must validate signatures when crawling repos from PDS instances. Signature validation will probably also be mandatory as part of account migrations between PDS hosts. As a general principle, when receiving content from another organization or party it is probably a good idea: an ACME Club AppView consuming from an ACME Club BGS might not bother re-verifying signatures (but maybe they should!).