This seems incredibly well thought out, and seems like it solves some of the bigger issues with ActivityPub. I had no interest in Bluesky before; now I think I'll make an account.
It is hard to trust an "open network" that demonstrates time and time again that they don't respect and don't want to talk to anyone else. It also makes you wonder how many more common mistakes have slipped in the design simply because they reject common knowledge.
[1]: https://www.reddit.com/r/programming/comments/138hlf2/s3_dom...
What's the benefit of user@host? Deployment simplicity, you don't need wildcard domains or wildcard certificates, or worse DNS API access, you can just self-host one app at one domain like everything else. As for who uses this format: email, matrix, XMPP, mastodon/ActivityPub, gnusocial/friendica...
You're coming up with excuses not justifications. And "it looks like it hasn't hurt us too bad yet" is not a great one at that. Self-hosted deployments have barely started rolling out (well, relay is still centralized).
> Deployment simplicity, you don't need wildcard domains or wildcard certificates, or worse DNS API access, you can just self-host one app at one domain like everything else.
At this point, they are not significantly more difficult than single domains or certificates, thanks to Let's Encrypt and ACME. In fact the requirement for domains and certificates has been always the single biggest hinderance, which inherently prevents self-hosted deployments in masses. Self-hosting is definitely a good option to have, but it is unreasonable to assume that most users can have their own deployment even in the near future. Multiple companies seriously tried to tackle them and have failed so far. As such, individual applications are not in the good position to solve these issues.
> I pointed out both usability and security issues.
You only have pointed out security issues, which I acknowledged as a single actual mistake. And that only relates to the domain ownership check, so you can fix them without scrapping the entire scheme.
I can't really see which usability issue can arise from `@example.com` as opposed to `user@example.com`. For laypersons who would use federated instances, `@user.example.com` and `user@example.com` is literally a single character difference and doesn't really matter much except that `user@example.com` is much more prone to be mistaken as an email address (see below). For users with their own domains, any user name is redundant and `@example.com` is definitely superior.
> As for who uses this format: email, matrix, XMPP, mastodon/ActivityPub, gnusocial/friendica...
Among others, email is the only protocol that have achieved common usages, distantly followed by Mastodon. Everything else is a nerdy technology which doesn't count as "everyone else". I should note that I have operated an IRC server for more than a decade and I'm very confident that the number of public Matrix servers is even rarer than the dwindling number of public IRC servers. IRC was once popular only because there were no other alternatives, not because it was open (mIRC was a dominant implementation in its heyday anyway).
And even Mastodon doesn't exactly use `user@example.com`; it uses `@user@example.com` with a prefix `@`, presumably because it allows for shortened handles (`@user`) while avoids a confusion with email addresses, but that can be also done with a domain-only handle if desired. Like, that has been a feature of DNS for the entire time. The fact that both Mastodon and BlueSky doesn't use the exact email address format shows that the exact handle format is not very relevant, as long as it can account for distributed registration and verification and can't be confused with existing usages (i.e. email addresses).
People are deploying Mastodon, it will keep being an actually-federated network, and Bluesky can be a centralized could-have-been federated network run by a couple of companies. But is that the goal as you see it?
> In fact the requirement for domains and certificates has been always the single biggest hinderance, which inherently prevents self-hosted deployments in masses.
I'm confident that you never satisfactorily answered to that, and even more confident in my belief that such hinderance is inherent and thus should not be the foremost design factor. Unless you have a clear answer that can be universally applicable (that is, no "works for me and my friends", I too have enough technical friends who don't use Mastodon), please refrain from trying to claim otherwise.
This "conversation" has reached my threshold for puzzlement, so I'm dipping out. Let me show you how it feels to me with an analogy:
Some company is making a new revolutionary car. It gets about 10 miles of autonomy, can only turn right, and stalls every 100 feet. I point that out in the comments.
Then lifthrasiir shows up and says that some people have driven it successfully, that you can get anywhere by only turning right with careful planning, that most vehicles don't get a lot of autonomy only cars and trucks, that there are commercial services that will get the car where I need it to (by loading it on a truck), and anyway if I really want to get somewhere why don't I take a bus?
Sure, I never claimed that it couldn't be moved, or that it would prevent its owner from getting places. What I said is that it's a terrible car.
Because there’s no social incentive for anyone to set up and maintain relays and moderation service when divorced from actual communities, what’s left are purely financial incentives - paid service, advertisement insertion, data mining, information manipulation etc.
Also the centralization of data distribution and moderation means they are huge undertaking now, both in terms of hosting cost and human cost, it’s almost forcing these services to be commercialized, or you can say discourage anyone not Bluesky from setting up their own relay or moderation service.
For all the faults of ActivityPub, the extremely “gated community” like approach provides the social incentive for users to feel a sense of belonging to a server, and for the server owner and moderator to feel a sense of pride and ownership over providing service to their users. Being within a valued community also incentivizes people to donate to pay for server cost and moderation effort.
ATprotocol will technically allow multiple relays and moderation services, but in reality how many will actually materialize?
As such I feel judging social networking protocols from a purely technical and adversarial point of view (like ATprotocol does) is a mistake, sure you are now no longer beholden to a server, but at the same time you are divorced from a tight knit community and you no longer have skin in the game.
When you have nothing to lose (data, identity and community wise), that’s a double-edged sword.
are social incentives going to be enough long-term though?
I keep looking at this and thinking of three things: trust, security, and Reddit. These are actual questions, not arguments, I'm genuinely curious.
Can you trust an admin to host and police your social network? Moving servers isn't hugely difficult iirc, but it could be very disruptive and drama-ful. It would have to get pretty bad before people start to overcome the network effect inertia and actually move.
What is there to hold hosts accountable for security? The threat of reputational damage doesn't seem like it is going to mean much to pseudonymous volunteers, so what can be done to ensure hosts are properly protecting the system from promise?
Reddit moderators are, by and large, reasonable but there's a non-trivial minority who will do things like stage a coup against the other moderators, start arbitrarily banning or harassing people, or just straight up ghost the site and never follow up on the rules. same as above, what mechanisms exist to prevent or reverse or take over the actions of an rogue/absentee mod?
I'd say all the long-running forum based communities proves that yes it is. Not counting Usenet, IRC and other "old internet communities" which have withstood the test of time.
> Can you trust an admin to host and police your social network?
That's where the federated part comes in, you choose a server and admin that you trust.
Preventing people from moving server would be holding them hostage, breaking the fundamental trust of the platform and become public enemy numero uno overnight.
I really doubt anyone would do it, but yes the chance isn't zero. Plenty of people host servers with their real identity and reputation on the line though.
If you are still paranoid you can join a commercial server where by contractual obligation they have to provide service to you and allow you to move away.
> What is there to hold hosts accountable for security? The threat of reputational damage doesn't seem like it is going to mean much to pseudonymous volunteers, so what can be done to ensure hosts are properly protecting the system from promise?
Again, you choose your server based on your risk tolerance. You can go with the main mastodon.social server, or join a server owned by a real person you feel is reputable/trustworthy, or join a paid server.
And I would disagree about pseudonymous volunteers not caring about reputation damage, the vast majority of people would feel a sense of ownership over their online identity, especially if it has a lot of clout.
> Reddit moderators are, by and large, reasonable but there's a non-trivial minority who will do things like stage a coup against the other moderators, start arbitrarily banning or harassing people, or just straight up ghost the site and never follow up on the rules. same as above, what mechanisms exist to prevent or reverse or take over the actions of an rogue/absentee mod?
Reddit mods are not server owners, at the end of the day they know they're just hosting someone else's party so there isn't a true sense of ownership.
But if a moderator decided to go rogue? It's just like a forum isn't it? Either the owner gets rid of them or you're out of luck.
You can limit damage by backing up your followers and follows on a regular basis so you can rebuild your network if you are forced to create a new account on a different server.
With federated system come the freedom to chose your server and the consequences thereof, you're gonna have to take some personal responsibility by choosing a server that has a healthy community and a responsible moderation team.
At the end of the day I don't think a perfect system exists, they are just different sets of compromises.
I really misunderstood what you were talking about until you got here.
This mindset is extremely alien to me, so that's probably why it's so hard to make sense of this.
I am glad that you have a system that works for you, and that I have one that works for me.
After the Twitter debacle I'm done with the idea of being "married" to any network.
With ActivityPub I can see that: a form of headless ActivityPub server which provides an Inbox and Outbox, based on the DB. Such you can publish your own posts both on the web and into an outbox. And even better, you get reactions in your inbox, which you could possibly display on your own web pages with enough determination, similar how the Indieweb people do that with WebMentions. After all every Status in Mastodon/Fediverse has an url property.
With AT Protocol I’m a little bit at a loss. You could possibly expose your Backend as a AT-compatible Personal Data Repository, although that would be a lot of work, exposing a Git-like interface.
But I’m still wondering how one would aggregate reactions. It seems it would not be enough just to have a PDS, but also to run an Indexer/Relay, which indexes other peoples PDS. And not just the PDSs of the people you are following, but also the rest of the world – after all a Like or such can come from everyone. When running an Indexer you are pretty soon into Firehose territory. Too much for a single person website.
It really seems there isn’t a way for reactions to swim upstream – the social graph of Bluesky in a way lives in the Indexer/App View world, not on your PDS.
Maybe I’m wrong, but the AT Protocol docs are not very expansive on such points. Neither is Klabnik’s blog. Everyone talking about ATP seems to be excited about the Solid-inspired DIDs and PDS, but never talk about the transmission mechanisms. Whereas I’m sitting here and thinking that an ActivityPub Actor’s Outbox is already a form of PDS – and it has an Inbox. Addressable via the Web and findable via Webfinger.
Or at least, that’s my initial guess, would have to actually work through the design to know if it would work that way.
“Lexicons” are BS’s Not Invented Here variant of ActivityPub JSON-(LD) meta-syntax and the vocabularies. Obviously necessary for the transmission of information, but it doesn't tells you how that information is transmitted or in which direction.
You don't need to run a Relay yourself in order to see reactions; you instead subscribe to an existing Relay's firehose (such as the one that BlueSky PBC operates), and ignore anything that isn't "reaction-shaped" (matches the relevant Lexicon).
> Everyone talking about ATP seems to [..] never talk about the transmission mechanisms. Whereas I’m sitting here and thinking that an ActivityPub Actor’s Outbox is already a form of PDS – and it has an Inbox. Addressable via the Web and findable via Webfinger.
Here's my attempt to summarise the transmission difference between ActivityPub and AT Protocol: ActivityPub is symmetric and push-based, AT Protocol is asymmetric and pull-based.
With ActivityPub, your client talks to your server. The server handles both outgoing data (you making posts) and incoming data (viewing other people's posts).
When you create a post:
- The post is placed in your server's outbox.
- Your server looks up the servers for every one of your followers, and places your post in their inbox.
When someone creates a reaction:
- The reaction is placed in their server's outbox.
- Their server looks up your server, and places the reaction in its Inbox.
- Your website checks the Inbox, discovers the reaction, and handles it.
With AT Protocol, your client talks to your PDS and the client's App View. Your PDS handles outgoing data (you making posts), and your client's App View handles incoming data (viewing other people's posts). Relays are what provide transmission between the two: Relays subscribe to your PDS, and App Views subscribe to the firehose of at least on Relay.
When you create a post:
- The post is added to your repository on your PDS.
- The Relay pulls the post from your PDS and broadcasts it on its firehose.
- App Views see the post in the firehose, and include it within the feeds of users that follow you.
When someone creates a reaction:
- The reaction is added to their repository on their PDS.
- The Relay pulls the reaction from their PDS and broadcasts it on its firehose.
- Your website's App View (which might be your client's App View if "reactions" are also posts, or some other App View if this is a different kind of semantic data) sees the reaction in the firehose, and handles it (e.g. includes it within the feed of reactions that your website uses).
But in a way depressing: I fear subscribing to a firehose is not that realistic for small single person websites. Maybe you can filter the firehose subscription.
I feel that if you decouple the social reward and the grunt work of moderation and financial burden of hosting the relay, then the incentives just wouldn't be there to do the dirty work unless it becomes paid or monetized in some way.