Live data from Hacker News

I was right about ATProto key management

notes.nora.codes

71–80 of 198 posts

Re: I was right about ATProto key management

#71

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"?

Re: I was right about ATProto key management

#72

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 thei…

I'm not too familiar, but isn't there a way to host your own did:plc auth server?

Re: I was right about ATProto key management

#73
post #29

Earlier quoted context omitted.

So I agree with you that they should work like email -- but I've always said that Mastodon is better because it is like email; aka the power is in the nodes. What do you think is wrong about Mastodon? Genuinely curious because I also am super skeptical that ATProto brings anything that we really need.

ActivityPub supports a less compelling user experience for many people: you only have a partial view of the network (you won’t see all the replies to the posts of people you follow on other servers), no global search, etc

Technically the internet also doesn't have "global search" but people are able to get along just fine most of the time.

Re: I was right about ATProto key management

#74
post #22

Earlier 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…

Email is the prime example of federated communication. From protocol inception to painful expansion and aging protocol all until corporate apropriaton. But I still think federation is the way forward, absolute centralisation is bad I'll let you figure why, but absolute decentralization is also bad, limitations due to its nature, unusual working for most users... Meanwhile federation is right in the middle, and users…

People often mention email as an example of federated communication, but the way email works in practice doesn't entirely live up to that ideal. Good luck getting your own self-hosted email server to send emails that actually reach anyone using a major email provider; they'll just be blocked as spam.

In practice, email is much less federated than it seems. A significant proportion of people are just using gmail. You probably don't have to include that many providers to cover a majority of people in the US.

I think federation has promise, but federation in itself is not a solution. Technical approaches do not address the more fundamental issue that, regardless of the mechanics of the system, big players will have more influence on its operation and evolution. Thus we will always need sociopolitical mechanisms to restrict big players.

Re: I was right about ATProto key management

#75
post #22
post #2

It's written in anger, but I'm optimistic that this will eventually get fixed, and documenting bad experiences like this will help.

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…

We don't need large scale social networks in the first place. The Discord model of small communities is the way forward. Keep groups small enough for natural human social rules to apply. Slows down global dissemination of information for sure, but that's what the news is for, and anything important will eventually travel between communities anyway.

Re: I was right about ATProto key management

#76

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"?

No, OP is saying that they have over-engineered the protocol, and that this acts as an *effective* barrier to participation, regardless of whether it was intended or not. Bluesky's protocol is focused on twitter-scale use-cases, where every node in the network needs to be able to see and process every other event from every other user in able to work properly. This fundamentally limits the people who can run a server to only the people who are able to operate at the same scale.

Re: I was right about ATProto key management

#77
post #30

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?

Isn't that literally Bluesky? A PBC must act in the public interest.

Not exactly—a PBC is allowed to "balance" shareholder profit with "stakeholder interests. But at the end of the day, the money is still coming from the shareholders, and they're still looking for a return. They're required to be transparent, but that's about it. And there aren't really any penalties for not complying either.

Re: I was right about ATProto key management

#78

Earlier quoted context omitted.

I'll admit it's a bit charged, but I'm frustrated with bad faith takedowns of ATProto/Bluesky, while Mastodon (and it is Mastodon, not ActivityPub) solves almost none of the actual problems. I tried implementing my own ActivityPub server and the spec is so hilariously lacking that it's understandable that everyone just uses the Mastodon API instead.

ActivityPub isn't actually the spec of Mastodon. Treat claims of "Mastodon is ActivityPub" the same as you treat claims of "Bluesky is decentralised." Just expose the same interface Mastodon does and you'll be fine. Noting that almost nothing cares about the exact URLs you use, except for webfinger, but does care about the domain being the same as the right side of the @ sign.

> Treat claims of "Mastodon is ActivityPub" the same as you treat claims of "Bluesky is decentralised."

Not sure if you meant this in the way I read it, but I believe that Bluesky is pretty much decentralised and tidying up the last bits of that, and I also believe that Mastodon is functionally ActivityPub and probably mopping up the last bits where the open spec meant anything.

The problem with ActivityPub is that it was missing at least half of what would be necessary to do anything with it, maybe more. You certainly can't create clients with it, it doesn't define anything about writing, etc. It's good that it's an open spec, but I see it as closer to Open Graph tags on web pages than it is to a social network foundation. That's fine... but we treat "Mastodon" as open because of ActivityPub, when in reality almost the entire system is defined by a Rails API implementation and its idiosyncrasies. I see it as a problem that you can't participate in the network without implementing an API with one implementation, rather than by implementing to a spec.

Re: I was right about ATProto key management

#79
post #22
post #2

It's written in anger, but I'm optimistic that this will eventually get fixed, and documenting bad experiences like this will help.

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…

I don't disagree, but I'm baffled that, with P2P as your preferred outcome, your orientation toward federated infrastructure is one of opposition rather than support. It feels philosophically confused to me; they're your natural allies, they're a step in your preferred direction and they have an instance of real world success (well, to a degree) which is important. Whatever theory of change motivates this form of criticism of federated services can't be one that's, say, intentional or strategic about outcomes. It feels more first principles.

One might also ask why P2P thesis statements only ever show up deep in the weeds in comment sections in response to the fediverse when logically speaking they would make just as much sense if not more in response to, say, any post about Facebook as a company or social media writ large, or business news about acquisitions, consolidation of web infrastructure into fewer hands, enshittification, or escalations of control over platforms.

Again, I'm fully on board with the dream of P2P but it feels like Buzz Aldrin criticizing Neil Armstrong for not doing enough to bring humanity into the space age.

Re: I was right about ATProto key management

#80
post #22

Earlier 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…

> How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping?

You design it with those requirements in mind? There’s no fundamental technical limitation at play here.

Post reply on HN