Instead of endorsing any sort of a ATProto PDS or anything, I instead have it pointing to my ActivityPub (and other) identifiers in varying forms.
I'm probably the only [non-employee] user (or at least: one of very few) on Bluesky's infrastructure that has full custody and control over their own private keys for their did:plc identity, and yet I don't even have a Bluesky account. Unless I'm just uninformed of something buried somewhere allowing you to export at least one of your rotationKeys (not the signingKey, which is just for signing posts, etc). Because without that, you don't really control your identity at all, only Bluesky exclusively does.
Meanwhile, in this endeavor, I "only" had to:
Write a DAG-CBOR and CIDv1 encoder
Write a Multibase and Multikey encoder and decoder
Write a base58btc encoder/decoder
Write a base32 encoder
Write functions to compress and decompress a secp256k1 public key (involves crypto maths, for decompression)
Write some very adhoc ASN.1 DER encoding/decoding functions (just to encode a raw secp256k1 public key into PEM encoding, to feed to OpenSSL; and then extract the r and s values from the outputted signature from OpenSSL)
Write a function to generate a did:plc identifier, from the genesis operation
Write a lot of test code
With how scarcely some topics are documented, and how scattered many tidbits of info is: I swear some of this is almost intentionally a trap to sell consultancy.
@arcanicanis congrats! that is a whole lot of code to write from scratch. we would definitely recommend starting from an IPLD library (giving multiformats, CID, dag-cbor), and probably not using OpenSSL for the crypto bits. there are better or worse EC crypto libs, but encoding and low-S signature issues are common.
bluesky opened up self-control of PLC identities initially created through the app, including fully removing rotation keys. this was necessary to enable account migration.
@arcanicanis key mgmt can be risky and PLC updates mostly dev-oriented and disclaimed/scary; not very friendly or accessible yet.
curious if you have feedback, requests, or ideas! there might be small changes/additions to make the system more general purpose, or holes in docs/specs
It isn't necessarily documentation difficulties with did:plc itself, just maybe a lack of some prerequisite formats/encodings (and their justifications).
For example, with DIDs and Object Integrity Proofs in ActivityPub, I had described how/why each part fits together (all the way into Multibase, Multikey, JCS, etc), some history, etc in a primer on the concept: https://arcanican.is/primer/ap-decentralization.php (sorry for lack of responsive design, I need to finish up my CSS work on my unusual personal website). I'm sure there's probably some gaps in my overview.
Nonetheless, the details of DAG-CBOR and especially Multikey seem very scattered and difficult to find, if people don't know where to look. Also, previously from the ATProto docs, I can't remember if I could even find any section that mentioned where the did:plc spec was, or the mention of the plc.directory, unless I just overlooked it back then. I do see the "Identity" section does point to a GitHub repo on did:plc.
Part of why I've implemented much of it from scratch is partly to evaluate the totality of everything required together (as well as trust factors, as there are a lot of bad libraries out there that people put blind faith into), as technical solutions should be evaluated by the whole of all it's dependencies.
For example, in the proposal for Object Integrity Proofs in ActivityPub, just JCS (JSON Canonicalization Scheme; RFC 8785) is needed to canonicalize JSON-like data into deterministic format for sign/verify, versus bringing in a whole system of compacted binary JSON-like serialization with additional semantic tagging (to denote CIDs), mainly just for the sign/verify use. The bigger the stack is, the more burden it creates with porting things in new/uncommon languages.
Generally I hold the belief that something is only a standard when people are able to make their own implementation from the text of a standard, and not just importing a vendor's library instead. It's part of what distinguishes the crowd of XMPP vs Matrix. You typically have the kind of people that have actually tried to implement a standard themself, versus those that only participate as an end user (just importing a vendor lib, or parading about a cosmetic UI/UX). I don't believe something is a standard until there's at least two complete independent implementations (by separate development groups---e.g., not just some of the same Matrix dev team making Dendrite too).
The motivations with my projects are primarily self-contained, minimal PHP implementations that people can just toss on any conventional hosting provider (such as a typical LAMP stack), and be able to participate in the social web with very little technical knowledge (just knowing how to get hosting, a domain, and extracting some files). If something can work in constrained less-privileged environments, then it allows more opportunity for people to self-host.
In ActivityPub, the bare minimum needed for someone to participate is just a generic webserver that serves objects (that can just be plain files) served with a application/activity+json media type, and just some dynamic code at their inbox endpoint to handle inward activity. WebFinger could even be accomplished as a basic URL rewrite. Even the end user could handle delivery entirely client-side, as long as they have custody of their keys (and as long as the recipient server permits it with CORS). The rest can be incrementally built up as icing on the cake (access control, timeline generation, etc).
With periodically orbiting/skimming the ATProto docs, I don't have a clear image of what the bare minimum implementation profile is with ATProto. I don't know if I'm even able to experiment, or if I'm supposed to wait until federation is opened up (or if Bluesky even will open up federation with obscure single-user instances, and if it has to go through an approval process, etc). I don't know if someone can build their own PDS (and other components, if needed) and just start directly following anyone, without requiring any intermediate infra inbetween just to start getting a chronological timeline feed.
@arcanicanis@bnewbold I think the other problem with bsky federation is it was released with little fanfare outside the site, it was overshadowed by the drama with the AP bridge, and most importantly it has the classic "standards?" problem, as many people who care about federation already run something ActivityPub and Matrix or XMPP. AP being around for years has led communities to use it.
Furthermore, many of the people who care about/use bsky are perfectly content posting on bsky.app and at most buying a domain for a vanity username. They're the more mainstream internet types (being safe edgy at most), and the mainstream internet users don't care about self hosting but rather "what new website can I go to now that (site here) is dead?"
So there aren't many github bugs reported for the PDS as a result, because there's no interest here and there's only some with the nerd side of bsky.
Add comment