BlueSky has to be centralized right now because the quality of the federated network is too poor right now.
I am not convinced that is not by design.
I was right about ATProto key management
41–50 of 198 posts
Re: I was right about ATProto key management
#42"View -> Page Style -> Basic Page Style" is required to read any of the text.
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
Re: I was right about ATProto key management
#43Earlier quoted context omitted.
Unfortunately, the swarm is 99.99999% advertisements for penis enlargement pills. How can a P2P system filter them out? A federated system relies on each admin to filter them out. A centralised system does even better, relying on a single dictator to filter them out. A P2P system requires every user to filter every spam message, together consuming far more effort than the spammer needed to send it.
This isn't, and has never been a hard problem. Just pay for people's attention. People you follow don't have to pay, and make that transitive. Penalize people in your network who propagate spam by increasing the cost to get your attention.
If a scammer, advertiser, or some other form of spammer can get a payout just 1% of the time, they will be willing to pay much more than the average person posting the average tweet.
If you make everything explicitly transactional, you will be left with only people trying to make a profit.
Re: I was right about ATProto key management
#44Earlier quoted context omitted.
This isn't, and has never been a hard problem. Just pay for people's attention. People you follow don't have to pay, and make that transitive. Penalize people in your network who propagate spam by increasing the cost to get your attention.
If a scammer, advertiser, or some other form of spammer can get a payout just 1% of the time, they will be willing to pay much more than the average person posting the average tweet. If you make everything explicitly transactional, you will be left with only people trying to make a profit.
You have the graph of everything you follow, the graph of what they like, second order graphs ...
There are so many heuristics and models you can use to filter.
Re: I was right about ATProto key management
#45> 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…
So suppose someone had a domain and a Bluesky identity associated with it. They deleted their account for whatever reason and let the domain expire. Later, someone else bought the domain, but since it had a previously-deleted account associated with it, it's permanently banned from identifying a Bluesky account ever again. Do you really think that's adequate?
I really like the ActivityPub approach more. There, if a domain changes hands, so potentially do all accounts associated with it. An account can be permanently deleted by sending a Delete{Person} activity to the network, but that doesn't prevent an account with the same username from being created again.
Re: I was right about ATProto key management
#46This 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?
No we can't. Beacuse at anytime people like Elon Musk can come in and mess everything up. If all of your data is in someones server you are one ban away from becoming noone. Of course that is still true with atproto since majority of users are on bluesky PDS's. But the whole tech is being designed in such a way to prevent such issues while still looking and acting qs traditional social media.
Re: I was right about ATProto key management
#47> 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…
So suppose someone had a domain and a Bluesky identity associated with it. They deleted their account for whatever reason and let the domain expire. Later, someone else bought the domain, but since it had a previously-deleted account associated with it, it's permanently banned from identifying a Bluesky account ever again. Do you really think that's adequate? I really like the ActivityPub approach more. There, if a d…
Just to be clear, this is specific to did:web, did:plc does not have the same downsides (it has different ones).
Re: I was right about ATProto key management
#48Earlier quoted context omitted.
Peer to peer, not federation, is the way forward. We should only build peer to peer social protocols. Websites and communities should simply sample from the swarm and make it easy for non-technical users to post and consume. They should be optional and not central points of failure (or control). {Twitter, YouTube, Reddit, Instagram, TikTok, WhatsApp, Discord} should work like {Email, BitTorrent, PGP}. Bluesky and Mas…
Bluesky is designed the way it is because of scale. How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping? Bsky is designed so that the microservices themselves can be decentralized and so multiple different types of apps can be built on the same protocol/infra. Obviously, it’s early days, and hopefully there is even more experimentation in the p2p space. But at…
You use routers as the beefy servers. Unicast, multicast, broadcast.
Unfortunately that means the implementation needs to reach all the way into the network layer.
Re: I was right about ATProto key management
#49This 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?
The bigots and sociopaths will need a place to exercise their freeze peach. Groups that don't want to be involved with that rancor need a way to evict such people when they are disruptive. Wikipedia hangs on with its NPOV policy. You can't do that on centralized open fora where opinion is the currency of the realm.
Re: I was right about ATProto key management
#50Earlier quoted context omitted.
Bluesky has been asymptotically approaching full decentralisation. A few years ago the gap was everything except a decentralised design, then it was AppViews, now it's "tooling and documentation" for the bit of the PKI that only 50 entities have done. Meanwhile I lost my Mastodon account history because I moved once, couldn't interact with half the network or apps because I was on a non-Mastodon codebase instance, lo…
> all classic signs of centralisation. No, these are classic signs of decentralization. > I lost my Mastodon account history because I moved once Your posts still exist on every server that federated with you, there's just no central authority to coordinate reclaiming them. > couldn't interact with half the network or apps because I was on a non-Mastodon codebase instance Independent implementations having compatibil…
Being beholden to a particular server I have no control over sounds like what happened with Twitter/X.
The posts might exist, but they aren't associated with me. Why not? Because I was locked into somewhere and unable to vote with my feet and go elsewhere.
Maybe I stopped paying because the instance owner enforced sanctions against my country? Why should I lose my identity because of that?
> Independent implementations having compatibility issues is what happens when there's no central authority enforcing conformance. Frustrating, yes, but it's a symptom of decentralization.
Compatibility issues means lock-in to instances under individual control. Shared protocols means lock-in to a protocol, but ultimately freedom to move. We know that open protocols trumps opt-in collaboration by private entities for freedom.
> You could host your own instance, and nobody but yourself can revoke your access.
See also: instances not federating with other instances that are too small. You technically can, but in practice it goes nowhere.
> On Mastodon, if something goes wrong, nobody can cut you off the network entirely.
Bluesky is not perfect, but where it's approaching full decentralisation quickly on a solid foundation, ActivityPub has become the Mastodon show, and is less a decentralised social network, and more a federated set of centralised services with little accountability to users. You can't move, you can't control the content you see, you can't even search. It's a reversion to the days of 14 year olds drunk on power as a mod on a phpbb forum, or the Reddit mods of today.