Compatibility with existing systems can be a concern - eg the OBR might still have had this problem due to the Download Manager plugin. Really wants to happen in core. (Compatibility not so much an issue for us.)

Yeah, although then you lose the ability to easily browse your files. A suffix on the filename would work too - I think we should definitely consider it in core, given there’s been multiple big leaks this year from it.

This is also an issue that happens with other CMSes too, but usually they’re slightly better protected. And of course, it’s possible to fix it for WordPress - we do on @altis.cloud :)

We could potentially build random IDs into uploaded files, which would be better than nothing.

I found out more over the last year as we worked on FAIR, but I also found out more specifically this week, when I was building a Glossary plugin for WordPress we needed for the FAIR website.

progressplanner.com/catch-up-to-...

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.