If you mean the buggy and badly documented process, sure.
But the complaint it builds up to is that instance-wide bans can ruin you when there are super big instances, and that's not something that can be fixed.
My experience using ATProto is that it is somewhat like how the nascent blockchain apps were when they first came out: there's no written content that is viable. Instead, you're supposed to use ephemeral conversations and read a widely disparate set of notes in order to use it. In the end, the upshot of all this is that you get to use a slightly worse form of Twitter - which is already rather unpleasant to use for me because there's a lot of rage content there.
Microblogs are fun, and very often I can't justify a whole blog post, but I have seen that others just post their thoughts intermingled and it makes me wonder if perhaps that is what I should do. There's not that much utility to the wide audience anyway. Talking to people who understand you is much nicer anyway.
Complexity acts like a gate. When we make the code too hard to understand, we are telling regular people that they are not allowed to participate. True ownership of your data is only possible if you can actually afford to host it yourself. We should focus on making things simple enough for anyone to use.
Can you clarify - are you implying that BlueSky team made protocol hard on purpose, in order to "tell regular people that they are not allowed to participate"?
fair enough, the did:web flows are not documented even for technical atproto developers, and there needs to be a self-serve way to heal identity/account problems elsewhere in the network (the "burn" problem).
I do think that did:plc provides more pragmatic freedom and control than did:web for most folks, though the calculus might be different for institutions or individuals with a long-term commitment to running their own network services. But did:web should be a functional alternative on principle.
I'm glad that the PDS was easy to get up and running, and that the author was able to find a supportive community on discord.
You can host your own instance, but resolving forks is not self-authenticating and requires some central trust (because of the 72 hour rollback window for higher priority rotation keys). Not counting that, you could essentially run your own fully independent instance where the worst that could happen is that you lack some newer updates to people's did documents (but anyone can upload them since they're self-authenticating). Some people do run their own instances for caching reasons, but these just ingest operations from the official one.
In terms of "credible exit", if the community at large could decide to move to a different PLC host, it would be technically possible for everyone to switch over.
Worth mentioning that Bluesky PBC is relinquishing legal control over the PLC and spinning it off into its own entity based in Switzerland.[1]
Key management shouldn't have to be difficult. Consider another open microblogging protocol nostr. There a keypair is crucial to the experience and every client automatically generates one if you don't have one to import.
I think this part of the UX is just being neglected by bluesky.
> why is a centralized “burn” able to completely prevent me from interacting with people using Bluesky?
Presumably to stop credential reuse attacks on Bluesky itself?
Bluesky is one instance and they should enforce security on that instance. If you use a previously burnt ID, they have no way to tell it's you (indeed that's the whole point!)
I've done some work in the DID space. Not really a fan, and the space is full of half working implementations like this post documents.
> I've done some work in the DID space. Not really a fan, and the space is full of half working implementations like this post documents.
I would be curious to hear your broader thoughts. I haven't actually worked with did but I did read through a large portion of the spec back before bluesky first launched. My impression was that it's a genuinely useful direction to go in but the standard seemed verbose and overly complex to me given what it does. But then that's not an uncommon thought to have about something you don't properly understand. (TBF I also feel that way about a lot of standards that I do understand reasonably well so perhaps I'm the problem here.)
Much of DID itself is basically a standardization of the idea behind Keybase, ie, using control of a private key as a marker of identity.
This in itself is a pretty good idea (with some bad usability, but at least technically interesting)
DID falls over because it has a bad interop story, and much of it is based on crypto-based implementations (again, technically interesting but bad usability plus a monetary incentive to go after your details).
This continues to confirm for me that there's nothing particularly valuable about ATProto, and that some of the percieved "flaws" in models like Mastodon's model are features just as much as bugs.
Honestly, this is making me go further in the other direction, can we just do "twitter but owned by a trust" or something?
Im sorry this is stupid. If you have to rely on one organization or a chain of systems where there is single point that can be effected, If your data does not live on your machine (PDS) then you are not in control.
Decentralization is the new Centralization. For information ownership, the protocol needs to be distributed.
Bluesky also randomly bans new accounts saying they violated the ToS. Like right after signup before you do anything. It says you'll receive an email with details (never happens) and offers a form to appeal. The form goes nowhere and you never hear anything again. This happened to me a couple months ago so it's probably still an issue. It seems more like sloppy, careless engineering than malice, however.
25 comments
[ 2.7 ms ] story [ 53.7 ms ] threadBut the complaint it builds up to is that instance-wide bans can ruin you when there are super big instances, and that's not something that can be fixed.
https://github.com/bluesky-social/atproto/issues/3143
Microblogs are fun, and very often I can't justify a whole blog post, but I have seen that others just post their thoughts intermingled and it makes me wonder if perhaps that is what I should do. There's not that much utility to the wide audience anyway. Talking to people who understand you is much nicer anyway.
Working outside of did:plc is a choice - this project is on the very ragged, least baked edge of Atmosphere development.
I do think that did:plc provides more pragmatic freedom and control than did:web for most folks, though the calculus might be different for institutions or individuals with a long-term commitment to running their own network services. But did:web should be a functional alternative on principle.
I'm glad that the PDS was easy to get up and running, and that the author was able to find a supportive community on discord.
In terms of "credible exit", if the community at large could decide to move to a different PLC host, it would be technically possible for everyone to switch over.
Worth mentioning that Bluesky PBC is relinquishing legal control over the PLC and spinning it off into its own entity based in Switzerland.[1]
[1] https://docs.bsky.app/blog/plc-directory-org
I think this part of the UX is just being neglected by bluesky.
Presumably to stop credential reuse attacks on Bluesky itself?
Bluesky is one instance and they should enforce security on that instance. If you use a previously burnt ID, they have no way to tell it's you (indeed that's the whole point!)
I've done some work in the DID space. Not really a fan, and the space is full of half working implementations like this post documents.
But this particular criticism seems unfounded.
I would be curious to hear your broader thoughts. I haven't actually worked with did but I did read through a large portion of the spec back before bluesky first launched. My impression was that it's a genuinely useful direction to go in but the standard seemed verbose and overly complex to me given what it does. But then that's not an uncommon thought to have about something you don't properly understand. (TBF I also feel that way about a lot of standards that I do understand reasonably well so perhaps I'm the problem here.)
This in itself is a pretty good idea (with some bad usability, but at least technically interesting)
DID falls over because it has a bad interop story, and much of it is based on crypto-based implementations (again, technically interesting but bad usability plus a monetary incentive to go after your details).
Honestly, this is making me go further in the other direction, can we just do "twitter but owned by a trust" or something?
First time I've heard someone say that
Decentralization is the new Centralization. For information ownership, the protocol needs to be distributed.
feels like the new "btw i use arch"