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.
Yep, I encountered the same problem. Initially it was solely API-based, but as they got locked down and paid-only and removed entirely, I went the bulk download route.
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.”
None of the concerns I've raised are about alignment. I'm not concerned for Bluesky's investors. I'm concerned about the long-term viability of the platform given its adoption curve and its financing.
If it helps, nothing I'm saying has anything to do with whether ATProto will succeed. ATProto could succeed (and fulfill one possible overarching goal of the PBC) and Bluesky would still not be a long-term viable forum for scientific communication (because it will stop existing in its current form).
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.
I don't mean to devalue your experience, nor imply that it is somehow less valid due to it happening to be our society's default "happy ending", for clarification.
If the default happens to work for you, that's awesome, and in fact it's probably what will work for most people - otherwise it wouldn't be the default.
I'm just against considering alternative ways of finding happiness or purpose as consolation prizes, bittersweet stories, or somehow less valuable or beautiful than others. There's effort in keeping a marriage working for decades; there's also effort in daring to leave an unhappy comfort zone to find better ways, or simply to learn to live life in your own terms if "the one" never appears for you.
Also speaking personally, I know more divorced couples than married couples, and have seen a married partner (who has a child) cheat on their spouse for going on a decade “because it’s the path of least resistance.” Also saw someone during a divorce light $100k on fire (from combined assets) in lawyer fees just to spite the other person (who had exhausted all options in attempting to repair the relationship before asking for the divorce).
Everyone is winging it, and the only beauty is in finding happiness while causing the least harm to others (imho). Do the best you can with the information you have, maybe it works out, maybe it doesn’t.
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.
> 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?
Functionally, how different would this be from the status quo? Between the FAANGs basically already having near-universal identifiers for all of us and everyone's information being leaked in a variety of breaches to where it's essentially public knowledge to any black hats or state actors I'm not sure how down the downsides are?
DIDs make use of public key encryption, which does not require storing private data on a public chain to be useful. All that's needed is a public key directory for public entities, everything else can be verified based on said pubkey of those entities who issue credentials
a new identifier (pubkey) can be created for each organization you engage with
OPs argument seems based on imagination has nothing to do with how DIDs are meant to work
Well DID spec doesn't tell us to put identity or related keys in public. DIDs coupled with the VC model (https://www.w3.org/TR/vc-data-model/) allows identity credentials issued by any "trusted" issuer to be validated. Here trusted means whoever the user trusts, be it government or big tech or anything else.
The issue is not other identity information in the DID, it is the identifier mandate itself is antithetical to privacy.
Having a global identifier as you go about the internet means that parties can correlate and share information about you.
Trying to solve that by isolation (using a DID per party you want to interact with) negative affects their usability and privacy properties with verifiable credentials.
Then there ought to be a way tp cheaply produce verified but ephemeral identities, which may be discarded after a particular transaction.
User: I want to use this site.
Site: we need your trusted identity.
User: Trusted Third Party, please make an anonymous identity for me.
TTP: I know you, user; here's your new identity.
User: Site, look here, TTP which you trust says I'm legit.
Site: OK, transaction completed. '
User: (destroys the identity's private key.)
It's not very different from TLS certificates, or OAuth tokens, or even ephemeral credit card numbers. The thing is to have a common Trusted Third Party, and somehow keep the number of such parties large enough.
> The thing is to have a common Trusted Third Party, and somehow keep the number of such parties large enough.
Aye, there's the rub. What's to stop most sites from only allowing Google/Facebook as the Trusted Third Party? And you also need to worry about security breaches, or one company quietly buying up all the independents, or governments legislating in back doors, or every service you use ganging up behind the scenes to try and collate your "anonymous" public keys back into a single identity.
Don't get me wrong, I do think there's a way forward, but it's not going to be easy.
It means: "TTP certifies that the user presenting identity X is indeed a user known to me, and is an acceptable user for the purposes that Site asked about: not a bot, not a spammer".
The idea that TTP certifies User against particular requirements of Site, and gives User an identity which User can give to Site. TTP keeps the "real" identity of the user hidden from Site, replacing it with a temporary identity.
TTP does not givel Site anything; User shares the temporary identity with Site. Then Site can check the identity, cryprographically and/or by asking TTP directly.
The identity should also be checked by a challenge-response protocol between Site and User, so that stealing it from User would be pointless. E.g. User keeps the private key and Site receives the public key, and Site asks to encrypt a random string, then tries to decrypt it.
> It means: "TTP certifies that the user presenting identity X is indeed a user known to me, and is an acceptable user for the purposes that Site asked about: not a bot, not a spammer".
How does the TTP know that the user isn't a spammer? Is there a backchannel for reidentifying users in case of abuse allegations? Does the TTP just refuse to issue credentials on behalf of the same user very frequently?
That's incorrect. DID make use of pubkey cryptography to create a new identifier for every entity one operates with... this argument is based on imagination
Where did you get the idea 'global' from?
Have you seen Peer DIDs? Most specifications advise you to create limited purpose identities. Use a widely known one when it suits you, like a LinkedIn profile, or Twitter page.
Exactly. DIDs don't need to be global identifiers. I can create multiple DIDs. Maybe one of them gets issued an identity VC. When required I may use that DID to prove my identity, otherwise use the other DIDs.
But what would be the solution? I've already played around with DIDs and Verifiable Credentials in the SSI-context and I like it from a tech perspective. I am also not sure if the spec should be held accountable to potential privacy misuses – the user should be. Additionally, you don't have to use the big tech solutions. The tech is inherently open, just look at the many DID methods.
But what I am concerned of are consortium (identity) networks like Sovrin which are run by a hand full of companies. At least in Germany, the government is starting to like what they are doing which is horrible imo. The identity layer of a state should not be governed by a consortium of private companies, no matter what fancy governance model they have.
The assumption that DID has to be in a public chain is flawed.
You should really look at DID use as a mechanism to decentralised the use of certificates. In my mind its definitely not not very different from PKI based certificates or any token based solution like OAuth. The difference is its potential to be decentralised.
DIDs do not specify keys should be written to a public chain, another commented mentioned the VC spec.
Another thing to look at is the did:peer method, it allows you to have a direct connection with a party for secure communication. Either party could root their did against a public key (eg a public organisation) but that is not required.
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.
Hey Jeremie! It's really awesome to have you here!
I've tried to dig up some more historical background besides of the Slashdot announcement, but failed. Do you happen to have an old copy of the 1999 changelog / code base (maybe a backup of the CVS or SVN server), just out of historical interest. The archive.org history only goes back to around 2004.
Also it's really amazing how far you've been looking into the future back then...
I remember decades ago seeing it come out and thinking we already have irc and email and chat. Why throw in "with xml" and think it's going to be better.
Telehash has been waiting for the right time to get focus again. We've been very busy with our other work currently, but it is in no way forgotten. We're hoping to come back around to it soon. Message us on our Slack if you'd like to chat more.
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...
How is work on Telehash coming? I'm still waiting for an XMPP equivalent for the mobile age that will free us from the medieval [1] state of communication we are experiencing.
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!
reply