Trust Infrastructure on ATproto

I dont think this is a problem that needs solving.

If a user wants to use a separate did:plc account for other purposes that they do not wish to link to their primary did:plc account, they will keep those separate and will not need a method of linking them together.

Also there are other ways of linking identities together eg the (at)bsky.team and (at)name.bsky.team is a clear way of verification of org members.

I personally dont care about sybil resistance for the sake of one human one account (I think thats backwards, humans can have multiple identities to express themselves across different social contexts), I care about clearly identifying bots vs humans.

1 Like

@gui.do Thanks for the response. I should have pointed to @ngerakines.me code for sattestations (both the sattestor and the sattestee) though definitely a work in progress. Amongst other things, he plans to rewrite all the rust to python; Nick please correct if I misrepresent you. (To answer a possible implicit question, for all relevant purposes I basically cannot code. So code for this is all Nick—so far.) Also by sattestation I mean a specific claim that the sattestor has checked that a meaningful identifier (so far handle and/or registered domain) and a self-certifying identifier (so far DID and/or onion address) are bound together under control of the same entity, and signed by a private key of the sattestor (self-authenticating as assoc with the sattestor’s identifier). This binding may or may not also have a contextual label that the sattestor asserts they have : medical doctor, entity local to the town of Springfield, Bluesky employee, atproto-developer-site, atproto-event, cheese monger, etc.

And this works as an implementation of what you said in your reply to @snarfed.org: if Alice and Bob want to each attest to the identity of each other, as well as to their being collaborator’s on project foo, they can each sign a sattestation for the other. For Alice’s endorsement of Bob, she signs a CID that can either be placed (signed) in Bob’s PDS or posted in Alice’s PDS to be picked up by the firehose. There are advantages either way. A sattestation should only be accepted if it is also asserted by the sattestee (e.g. by the sattestee signing and putting it in the sattestee’s PDS). This provides an element what I call authority independence: nobody else can make claims about you that you don’t accept or that you cannot retract.

2 Likes

Arggh. And here’s the link that I again failed to provide to Nick’s code GitHub - ngerakines/atonion Ā· GitHub

1 Like

I like to see this. I wrote some notes about trust + verification here: GitHub - mycelial-systems/cawg: Creator Assertions Working Group Ā· GitHub

btw, trust on the internet was a big part of SSB culture, see trustnet — alexander cobleigh / cblgh.org

2 Likes