While did:plc was intended to be centralised from the start and under open governance (https://docs.bsky.app/blog/plc-directory-org), did: provided a framework to adopt other key resolution methods.
As part of the IETF work (https://docs.bsky.app/blog/taking-at-to-ietf) this is a hotly debated area and I’d expect some solid evolution to happen as part of that process, super encourage anyone interested to get involved there!
It was a different era 15 years ago, made some decent inroads on an API based approach with the Locker Project https://en.wikipedia.org/wiki/Locker_(software) but the platforms quickly started gimping the APIs and exports/takeouts were non-existent or too early yet back then, so ran out of steam.
I’m one of the (independent) board members of Bluesky and I can say with confidence that I don’t have any of these concerns, everyone involved is deeply aligned to the PBC’s purpose of “To develop and drive large-scale adoption of technologies for open and decentralized public conversation.”
Great memories! Back in ‘98 I found a floppy with my original 1994 Netscape Mosaic v 0.93 Beta and shared a bunch of tidbits about it on my personal site (thank you Internet Archive!):
I am also on the Bluesky board, and while the original funding did come from Twitter (at Jack’s direction), the company has no control over Bluesky and it is 100% independent.
> I do deny it; or to be clear, I think it is a story that we've been conditioned to prefer over the others
Speaking personally, and perhaps it is indeed my conditioning, but at 25+ years of marriage I am living that beauty in 1 every day and I know without a doubt it has led me to my best possible life.
This should be v0.1 based on the actual utility of the spec, just because it's been incubated for so long doesn't magically make it useful.
DIDs are fundamentally antithetical to privacy and will only enable a deeper and more obscure level of tracking to all applications that use them. They were originally inspired for mapping public blockchain use-cases, but IMO personal identity and related keys should _never_ be put on a public chain, who thinks this could ever be a good idea or architecture?
All of the suggested "workarounds" to layer on privacy to DIDs are just lip service in the spec, there's zero technical requirements for an implementation.
I worry that DIDs based on this spec will be deeply harmful if widely deployed with the multiple layers of abstraction, required dependencies on massively complex things like JSON-LD, and abundance of implementation-time choices. It's such an easy "spec" to embrace and extend by big tech, it has no teeth to prevent tracking abuse and it should develop those as hard normative implementation MUSTs before v1.0 versus the non-normative "Privacy _Considerations_" it has now.
I’d say that it feels like just yesterday, but it totally feels like decades ago :)
I’m very lucky to still be close with so may of the truly amazing individuals that helped build Jabber, and over the years deeply honored by all those that spoke to me about how it inspired them.
While at the surface it may seem like all of our efforts had little impact on the big “messaging silos”, I am most proud of how much Jabber/XMPP has made it easy for anyone to build/host/extend a messaging and presence service. Twenty years ago the concepts and architectures were opaque, now they’re commonplace.
Personally I have a much broader use case in mind for E3X than QUIC is designed for, incorporating IoT and meta-transport / end-to-end private communication channels. So, I expect they'll diverge more as they both evolve...
I'm a big believer in a (local/p2p) transport encryption mechanism /in addition to/ one for auth, and for it to be transparent to any UX... that's very much our goals for telehash v3 :)
I've been on both sides of dizzyd's interview process and highly respect it, he should be a mentor to other software engineering managers on how to improve their hiring practices.
I'm leading an effort for a pretty large refactor and cleanup of all of the existing telehash work (look at the commit history), honing in our mission and simplifying it's usability.
We're trying to make it easy for any developer to add/use end-to-end networking that has strong encryption and connectivity built in.
IMO, interop/federation is going to be a tremendous long-term effort and include many standards, but is definitely feasible, inevitable even. There's a lot of innovation happening in messaging again thanks to mobile, we just need to start taking the best of what we've all learned already and work together to improve everyone's stack collectively.
Pumped about this as well, it's the perfect packaging to quickly experiment with distributed sensor grids and be affordable to a hobbyist... pretty sure we'll see some cool "green" gardening (optimized watering), thermal/heating/cooling, power usage, farm monitoring, all sorts of great things built on this!
With a telehash style distributed messaging bus you'd need to have clients opt in to centralized reporting and analytics providers, like the library of congress, internet archive, even commercial firehose companies like gnip, etc.
As part of the IETF work (https://docs.bsky.app/blog/taking-at-to-ietf) this is a hotly debated area and I’d expect some solid evolution to happen as part of that process, super encourage anyone interested to get involved there!