p.s. you can find my slides at speakerdeck.com/rmccue/whats...

Your timing is impeccable, I just left one.

youtu.be/6kLGw3tbzmk?...

Specifically, it's is_utf8_charset() which reads the blog_charset option.

Something that's also fascinating is that the charset option in the Reading settings will only show up if it's not already set to UTF-8 - I guess it's legacy support?

Re multiple directories, I think getting the directory to a "neutral" (multi-stakeholder?) host solves that problem, in the same way we don't need third-party backups for the DNS roots.

The main thing there is performance, pulling the audit log data could require pagination and DID lookups are already relatively expensive in our flow (see also github.com/did-method-p...).

One option we talked about a little is that we could do validation in a labeler, making it opt-in.

(Also, the Bluesky client(s) you're using here use only the direct method fyi: github.com/bluesky-soci...)

Indeed, although what's the threat model? If the threat is the PLC directory server, then loading the audit log from the server is no safer than the single endpoint - only mirroring it elsewhere and checking for inconsistency allows that.

Might be a better question for @bnewbold.net & the Bluesky team on that, but I know there's tools to mirror the PLC directory, such as github.com/str4d/plc

(Note that we're using the single endpoint per spec, same as the official atproto identity package does.)

Your Bluesky account eg is plc.directory/did:plc:fd7x... :)

Each DID method defines its usage; the spec for PLC DIDs is to use the public endpoint. The audit log allows verifying it, but that's more of an offline process (and allows mirroring it).

We're also planning on supporting web DIDs, and potentially other methods beyond that - same as Bluesky.

eg for did:plc:afjf7gsjzsqmgc7dlhb553mv, the DID document is at plc.directory/did:plc:afjf... and the key is zQ3shsLDoduUAwJjcc93ktzeQPRMghThq7LPEcsauSjgHpKZT

You don’t need to parse the whole PLC audit log for operational usage, you can use the latest endpoint instead. The keys are encoded directly into the response in multibase. :)

Thanks for diving in though! Come join our slack at chat.fair.pm if you want :)

This isn’t quite right; the code for package signature checks is already in core, we just have to switch it on. It’s pending our server-side switch to Ed25519 before we do. It uses libsodium-compat, so should work on all hosts.

DAG-CBOR and multibase are byte encodings, no exts needed.

If you have it locally, definitely try it: www.tracklements.co.uk/product/swee...

It’s strong English mustard and wholegrain rather than American yellow mustard. Now tempted to try the combo!