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.
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.
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.
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).
Readit News
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.
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.
MIT licensed protocol code, public since May: https://github.com/bluesky-social/atproto
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.
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?
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.
irc died and discord boomed because there was a user generation change. an explosion of new users eclipsed the few irc old timers.
discord is garbage any way you look at it. dont try to sell it as fixing irc. lol.
https://blueskyweb.xyz/blog/10-18-2022-the-at-protocol
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.
Deleted Comment
I'll definitely bookmark this.
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.
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.
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".
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.
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)
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.
This is to be used in adversarial situations in which a user's signingKey leaks or is being held by some custodian who turns out to be a bad actor.
In a situation such as this, the signingKey may be used to rotate both the signingKey and recoveryKey.
From: https://atproto.com/specs/did-plc#account-recovery
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).
But also appropriated to control modern GSM and LTE chipsets, SCADA radio modems and who knows what else.
I hope my search results won't get polluted with this too badly.
It's pretty exclusively in the domain of embedded development now though.