If a team can't work within an existing standards body or a community (like the ActivityPub contributors) then they simply can't create an actually decentralized and open protocol/network. They can, however, create something that they can define and control for their own gain.
Rolling out this protocol on a site without a community forum or other discussion channel but simply a "give us your email address and we'll let you know when it's done" is a red flag.
Many of the world's strongest standards – including those of the internet – were standardized from work that first proved itself outside "standards bodies", rather than emerged from them. Standards bodies are better at codifying practices proven to work than bootstrapping new approaches, and quickly become highly-political impediments to innovation as the stakes grow & entrenched interests arrive.
Also, despite the ideals & good work of early ActivityPub work, in practice its server-centricity has already sent it many evolutionary steps down towards the same semi-feudal architecture as email & HTTP, where your identity, content-policies, & even privacy are at the mercy of your "home server" (feudal lord).
Even the real option to freely choose a new liege (at some serious switching costs) doesn't promptly or fully address this weakness, and the theoretical potential for practices to be radically different faces a giant "architecture tax" from the installed base, & costs/expectations of backward-compatibility.
Users of ActivityPub have already self-selected for those who are OK with such "home server" dependencies. Why, they find them "cozy" & even have (well-reasoned!) apologetics describing ways in which this user-homeserver co-dependency is good – for their needs.
So why should people with a very different vision, informed by both the limits of the giant proprietary platforms and of ActivityPub, fight a slow uphill slog in that community, as opposed to pursing a "green field" (or you might even say "blue sky") effort with fewer constraints? Appropriate formats & conventions from prior work like ActivityPub can still be reused, whenever helpful.
Two of the three pillars highlighted on the atproto.com homepage – portable accounts, and algorithmic choice – would require significant retrofitting counter to ActivityPub server customs to achieve.
(And the third, "federated social", is arguably an area that at-proto is erring by staying too close to the ActivityPub approach. We know what happens to 'federated' systems under network-economics: they trend toward semi-feudalism.)
But the fediverse doesn't use any algorithms, it just shows you what/who you subscribe to. This is the way social media should be. If I don't want to see something or someone I can just block them.
It's only gone downhill since the sites started adding algorithmic crap and filtering things out to increase 'engagement'. This made facebook totally useless for me to keep in touch with my friends.
Portable accounts are indeed important and a big thing missing from ActivityPub, I agree there.
But I'm completely over to IM now to keep in touch with friends. Social Media has invalidated its own usecase for me.
Yeah.. when I saw that and something about joining a waitlist for something that should be developed in public I noped my way out. I hope other people learn have similar BS indicators and don't fall for this stuff. There is nothing open about joining a wait-list.
The waitlist is just for the app. We've been developing the protocol in a public repo on Github for months, but most people don't have the patience to follow open source code development, so we'll notify them when we can put a usable app in their hands.
Wouldn't it be better to simply have a notification for the newsletter to keep people informed about the community work and where and how they can contribute. The page is full of content suggesting that users are simply to wait back while this supposedly open protocol is developed with no community involvement.
The fact they even felt the need to create another protocol instead of using, improving and contributing to ActivityPub makes me think they want to bake a busines modell for themselves into the technology and they can't do that if they don't have full control over the spec.
ActivityPub is organically grown from a community to serve that community.
Bluesky is created to combine making the profits of a commercial centralized social network + profiting from the investment from crypto bros.
ActivityPub is not perfect and nobody is pretending like it is (there is a big blog post from the co-author about what retrospectively they should have done differently, sadly I couldn't find the link), but a specification is not static !
If you have a suggestion to improve it you can propose changes and a lot of things are left to the implementation, so you can just do things differently than other ActivityPub application currently do.
In fact there are people building the future of the ActivityPub ecosystem right now: https://spritely.institute/
There is no need to create yet another specification.
The only feature this claims to have, that all ActivityPub implementations currently don't have is identity portability and that can actually be implemented without changes to the ActivityPub spec, just no ActivityPub Application has implemented it yet.
'The specification may be terrible, and everything good about it may be implementation-specific, and every touted feature you're looking for may be missing from the only implementations anyone uses, but you can always just break compatibility from all the de facto standards, and so that's no reason to come up with your own base standard' seems flatly wrong, and that actually is a pretty great reason to come up with your own base standard. IRC beat the 'the standard is just fine as it is' drum for many years, and they were so amazingly correct that basically all IRC communities jumped ship to Discord within the span of a few years.
Not to mention nobody uses Mastodon either. Who should Jack be trying to placate, exactly? The extremely few people who were so fed up with Twitter that they left for Mastodon, are they eager to finally start federating with Twitter?
The choices aren't "just break compatibility with all de facto standards" and "come up with your own base standard". You can work on an extension to the protocol that everyone can adopt and move to if it's really an improvement.
> The extremely few people who were so fed up with Twitter that they left for Mastodon, are they eager to finally start federating with Twitter?
I never was on Twitter, but I am a Mastodon and Pixelfed user. I have zero interest in the cesspool that is Twitter joining the Fediverse and if they did I would probably instance block them.
This is about standards and my suspicion, that they want to keep all the control and profits, but now want to call it federated.
> The specification may be terrible
Have you read it ? I haven't, but it is working pretty well for the Fediverse.
And once again: Standards aren't static, if you actually have a concrete problem with the standard instead of a gut feeling, that "it just sucks, don't ask about the details", then formulate it and bring it up to the creators of the spec or try to fix it yourself.
> IRC beat the 'the standard is just fine as it is' drum for many years
Well maybe that is the difference between IRC and ActivityPub. Nobody on the ActivityPub side is delusional enough to think the standard is perfect.
There can pretty much by definition never be a perfect standard. There will always be use-cases that were not thought of during the creation. The solution is not to create one standard after the next, it is to improve existing ones. 1000 Standards are as useful as no standard.
Well there is an IRCv3, so it is evolving. And honestly Slack/Discord don't bring that much IMO, at least for the cost of running on a damn ElectronJS app in a proprietary system. All that for what? Reactions to messages?
The fact is that average users don't make any considerations about privacy/freedom/technical merit: they just jump on whatever is used by their own contacts. Nobody is using Mastodon because nobody is using Mastodon. It feels like one solution to that would be marketing. And given who is behind ATProto, they may have a shot at convincing many people to use their new shiny app.
the gp is not saying discord is a better protocol, they’re saying 1) no one cares about activitypub as a protocol because it has one de facto implementation that deviates from the protocol and 2) making something new is easier when the goal is making something people actually use
the appropriate place to develop protocols is within IETF, W3C, or other open groups which I'm absolutely sure Twitter could have played a role within.
Kind of discouraging to see this PBLLC doing things their own way.
Seems very similar in goal to the Solid Project, https://solidproject.org, which Tim Berners Lee is involved with and is being standardized by the W3C.
This is very interesting. Unlike BlueSky it seems it uses the ontologies compatible with ActivityPub federation, which might prove a good compromise for interoperability in the future.
This is an interesting start. I have many questions though:
1. Why no public forum or (heavens forfend) a standards body community group, for the spec?
2. For the data model, why not use the excellent ActivityStreams2? The actual data model that contains the posts etc (https://atproto.com/lexicons/bsky-app) is a serious step backwards from the event-log architecture of AS2.
3. Why reinvent gRPC/JSON-RPC? Seriously, of /all/ the things to reinvent, why RPC?
4. I wonder what the team will do for authentication and authorization? Will they go the ACL route? (In which case, are they going to include Solid-style client identity, in the ACLs?) Will they go the capabilities route? (UCANs / zCaps). This is the genuine hard part.
Great to see some more concrete ideas beginning to come out of this team!
My main concern with the protocol design is in the identity, and how it lends itself to centralized name services (@alice.google.com). The end result seems like it will be no different than Mastodon and email protocol, where a few central players own the majority of the namespace and network effects prevent most users from having full custody & portability of their accounts.
A permissionless blockchain does seem like it would be a suitable solution, but your identity page mentions avoiding blockchain due to slow commitment times:
> At present, none of the DID methods meet our standards fully. Many existing DID networks are permissionless blockchains which achieve the above goals but with relatively poor latency (ION takes roughly 20 minutes for commitment finality)
What latency is really needed for a global name registry of a social network? I've only registered a few Twitter handles in a 10 year period, and each time I would be OK waiting for 15-20 minutes (or longer) to ensure commitment finality if it means I could escape the centralized host at any point in the next several years. Similar story with rotating keys and updating any pointers to my host/server.
> The end result seems like it will be no different than Mastodon and email protocol, where a few central players own the majority of the namespace and network effects prevent most users from having full custody & portability of their accounts.
You are correct about Email, but Mastodon ? Instance diversity is alive and well.
People don't choose Mastodon servers by the number of users that are already on it, but by what domain name they would like to have in their identity name.
People join the community they identify with ignoring "network effects".
Instance diversity in Mastodon is that ~2M users or 70% of the network chooses one of 5 main servers. If your account is @foo@service.com and service.com goes in an undesirable direction (it shuts down, or is bought out by a billionaire, or turns on ads or paid subscription) you may be forced to switch to another platform like @foo@alt-service.com. This requires that the service.com continually upholds and honours your redirect, which is to say that your account name was never portable across different and incompatible services to begin with.
Network effects dictates that most of the time you will just stick to the same domain you signed up with, because you don't want to lose all your DMs and posts, and you don't want to start over again with a new name.
I’ve not gotten fully through the spec, but why does the server hold the client’s signing key? That puts a lot of responsibility on a PDS that could be handled by the client, doesn’t it? If the client has their complete repo anyway, why can’t the PDS verify changes with a public key?
If it’s to aggregate likes, comments, etc., why not use a mailbox encrypted with the public key for unmerged data and allow the DID to decide whether or not to accept the content, aggregate it, and publish the updated repo? Other clients could choose whether or not to considered the merged mailbox when displaying to users (for example, likes could update automatically, but only accepted comments)
Basically -- to keep it simple. Holding the signing key in the PDS simplifies linearization and reduces device-pairing actions.
We spent most of the summer planning to store the signing key in the user device(s) but during a late design session we examined why exactly we wanted that, and realized the main reason was for account portability^1. Thing is, we dont need the primary signing key to be local for account portability; we just need a recovery key that allows the user to assign control away from the PDS later. So we switched to a server-held signing key, but we kept in the architectural pieces that make client-held signing keys possible, in case we want to explore that again in the future.
^1 We're interested in end-to-end encryption but that's not what the signing key would accomplish and will need to be developed later. Hopefully we haven't painted ourselves into a corner for that part of things.
Seems to suggest the signing key is all that’s needed to change the keys for a user? I was expecting it to say the recovery key could be used for that (which only I have).
Can anyone explain why Bluesky is making a new protocol instead of using ActivityPub like Mastodon? What advantages would it have over ActivityPub? https://activitypub.rocks/ Worth noting that ActivityPub is an official W3C recommended standard.
ActivityPub's PublicInbox is used to route all messages. This works for "small-world networking" where you're in a tight-knit community exchanging messages with known or friend-of-friend actors, but doesn't work well for "big-world networking" with folks you don't know and don't necessarily want to share all or even most of your messages with (a pretty big pain point right now in the Fediverse.)
ATProtocol claims to differentiate between these cases by introducing the concept of indexers which can apply different algorithms to order feeds, but it's unclear to me how exactly that will work.
This is not right. First of all, what do you mean by "PublicInbox"? Are you referring to the optional sharedInbox attribute, which allows delivering a payload to a whole server at once instead of iterating over the personal inbox of every actor on the server? Or are you referring to the inbox in general? The inbox is just a mechanism to deliver a payload from point A to point B. It is in fact used to receive messages from folks you don't know, but there is no obligation to share all or even most of your messages with anyone in particular. You can deliver posts to your followers, but you don't have to, protocol-wise, and you can choose, person by person, who to deliver to. The concept of indexers doesn't seem foreign to ActivityPub either. PeerTube runs sepia.search, which is exactly that kind of indexer that powers search for their video platform.
Sorry, yeah I meant "sharedInbox" vs "PublicInbox". My understanding is that the AP client (assuming you aren't using C2S ActivityPub) sends messages to your AP server which then either sends messages to the sharedInbox of the destination AP instance or directly to the inbox at that other AP instance. I realize the visibility of each message is up to the discretion of each AP implementation but as practiced now, messages are often seen by multiple parties before getting to the final destination.
As far as indexers are concerned, I realize it's entirely possible to use indexers with AP. It's wholly unclear to me how AT Protocol is using indexers or scoping any of their objects so I'm not sure it's worth belaboring the point.
Consider how worried people are about Google Chrome's browser market share, and how Google is increasingly able to dictate details of the web unilaterally. The Web is made of standardized protocols, but Google has significant control over it.
Consider the state of email, a standardized protocol, where Gmail is dominant, and anything that can't deliver to Gmail is practically irrelevant, no matter whether it follows the protocol.
Now consider Bluesky. If Twitter supports the AT protocol early, it would be by far the largest implementation, meaning that Twitter practically controls it. It would be like Gmail for email, except there are no other options to begin with. If Twitter does not support AT protocol early, then AT protocol will be irrelevant, and other networks like the ActivityPub Fediverse will continue to outpace it.
SMTP started without proper authentication so anyone could spoof anyone's address. Most of those extensions try to fix this. But ActivityPub, for example, has authentication built-in from the beginning in the form of HTTP signatures.
There are some technical differences like AT storing all content in a Merkle tree so it's easier to replicate, check integrity, etc. It's not clear to me how valuable these features will be. Perhaps the biggest difference is that they've introduced a username->server indirection layer.
The root gets updated with each update, and the diff gets exchanged as part of the sync protocol. Deleting and purging is no different than other federated protocols in that regard.
Rewriting the user's entire database on each delete sounds like it might become a problem. Especially as some users like to automatically delete old posts on a regular basis.
ActivityPub, the protocol, doesn't actually tie your identity to your homeserver. Webfinger (which is the protocol responsible for the username@domain addresses) is not part of it. In fact, even Webfinger doesn't actually "tie" your identity to your homeserver -- the fact that your identity is "tied" is an implementation detail in Mastodon and other currently popular fediverse software.
That’s a de-facto standard, so it’s safe to say that, given that all major AP implementations do so, your identity is tied to your homeserver.
The tyranny of the installed base is real. What you choose to ship basically defines what everyone else can do with AP in practice.
I think it’s a shame that Mastodon got a million fuzzy blinky UI features before the (still missing) BYOdomain support, given that everyone in that space links permanent identity to user+domain.
I don’t see that changing. Do you? It seems everyone has settled on this, just like email, and that the solution is to just use a domain that you control for your identity (just like email).
"Fuzzy blinky UI features" is what people actually care about though. You can have all the theoretical bells and whistles in the protocol but if you don't have a flagship application that people can use for their everyday needs, nobody is going to care. The fact of the matter is that "porting your account" is just a much less frequent need than literally anything else that people will come across in their day to day use, and the fact that you can move to another account in the fediverse without losing your followers is good enough for most. Of course it would be nice if the old and new accounts were verbatim, not even identifiably different copies, but we're talking about synchronizing (potentially, and likely on average) multiple gigabytes of data across small hobbyist servers that also still have to serve requests from other users. Not to mention the abuseability of being able to import gigabytes of pre-recorded content like that, a spammer's boon. Worth mentioning that the account portability approach described in ATP is just "upload your backup to the other server" which in practice is going to suffer from the exact problems I am describing.
What's the point? Social network software falls into 1) real software you use already with a dedicated circle of people who care 2) people who don't care and just use one of the relatively 'poor' common networks (e.g. twitter, FB).
Who is this marketed at?
Reading the comments it seems others are struggling to see the point - the existing communities are mostly served even if the software is not great. There's not enough value-add.
Came here expecting to read about an interesting protocol not a social network protocol without an app...
This seems really cool. I have looked at ActivityPub quite a bit and written a little basic client/server but the identity portability thing is pretty much a nonstarter for it to be taken seriously in normal circles. I’ve found the content quality of the fediverse to be abysmally low thus far, I think AT could work especially because of the big name behind it.
Twitter did the Ruby community a huge solid back in the day, and I’ve always been grateful ever since, but now the new web is coming together and I’m optimistic that this protocol could lead the way.
Time will tell how seriously they move forward with this.
I've found that quality on the fediverse is quite high, but takes curation and exploration to find people you want to follow. Once you have a good seed of people, it grows pretty organically as you follow people with interesting posts boosted by people you do follow.
It's the only social network that I've actually stuck with and enjoy, having tried and fallen of both twitter and facebook. A big part of that was unfollowing people who posted political stuff and following people who posted stuff about cool hobbies and whatnot
I understand that some people gain some sort of satisfaction out of this, but it mostly defeats the purpose for the average user.
Imagine you walk into a bar, and it’s clearly filled with neonazis. Someone says to you, “Hey! This is a great bar. You’ll have to curate your friends in here, but once you do you’ll find some great folks.”
It’s just silly to think the average person is even remotely interested in that. I’m a big fan of decentralized and p2p technology, but social networks are very much improved by strong, strict regulation at a central level.
Granted, I’m a dedicated twitter user, and I’m also interested in political topics and discussions, which you mentioned that you weren’t.
Twitter’s flavor isn’t for everybody. I think there should be more flavors in general, but what the fediverse offers is a different dish, different restaurant, different everything. I’m skeptical it will find much success outside of the sorts of people that use it now.
I strongly disagree with the analogy - it's much more like welcome to the big city! Where all would you like to hang out and make friends? The park? The sports bar? Sex club? Political rally? Neonazi hangout? Anarchist collective?
In the analogy each place is a different instance that you start following people on, with its own culture and interests.
I've not run across any neonazis that I'm aware of, I believe they tend to be blocked by most servers pretty quickly, though one could seek instances filled with them if they wish. I could see that if you were seeking political discussion the Fediverse might be less attractive, since I imagine it would tend to be more extreme (right and left).
That first clause is an exceptional claim. I don’t know anyone in the fediverse who’s there because they can’t be on Twitter. I do know plenty of people who left because it was becoming a raging cesspit of algorithm-driving extremism.
I don’t think I have time for a full review, but making $ext a map seems short sighted. In the example, a poll is included, great. What if you want two polls? It’s another level of indirection, but making $ext a list (unless the encoding protocol handles multiple values with the same key). This also allows for a specified ordering of extensions, provided that makes sense.
We're open to that possibility. We know the broad idea we want to apply with schema extensions, but we're still figuring out the right DX on the execution.
I'd love to know how Gargron (mastadon author) feels about json-ld.
Im just the peanut gallery but json-ld is pretty nice. Give people the right "context" & they can basically ignore that they're working woth json-ld, in a wide range of cases. But get real extensibility & interop with the other semantic web things.
Of course, writing maintaining & using the translators to flop between forms is more work!
Bluesky is Twitter's right? Will be cool if they come away with something actually decentralized. Trial in beta with hackers, then one day, in-place swap Twitter to run on it. Pipe dream?
While Bluesky PBLLC received initial funding from Twitter Inc, Twitter (whether under its current management or impending Musk ownership) has no ownership interest or veto-power over the Bluesky plans.
Though Agrawal seemed interested enough that Bluesky would potentially have had an 'inside track' to getting Twitter to interoperate, Twitter's proprietary platform interests may have always made that tricky. Under new management, anything could happen.
Me too; particularly as I've been using them quite a bit recently; AT lives on in embedded system network comms (e.g 4G, wifi, ethernet and/or bluetooth modules - the ESP32/ESP8266 has AT command support). It's really expanded a lot these days - you can do http(s) and mqtt requests, and even run a web server without having to touch a TCP stack.
I remember feeling like a magician when I first learned about AT commands. It was my first real experience getting the computer to do something physical. After that, I learned about all the IO accessible on the parallel port, allowing full binary access to the real world. I was hooked, and it eventually led to a career of making computers do physical things. :)
If you are talking to one of those self-contained, postage stamp-sized GSM modules using a microcontroller, chances are there'll be a serial link to it, and it's listening to Hayes commands.
Bullish that Dorsey is involved. Dorsey as a high status rich guy could attract lots of users and developers.
He’ll also kill activitypub as AT protocol will soon be much better funded with more developers.
Rolling out this protocol on a site without a community forum or other discussion channel but simply a "give us your email address and we'll let you know when it's done" is a red flag.