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.<p>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.
Nah thanks, I'll stick with ActivityPub.<p>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.<p>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.<p>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.<p>In fact there are people building the future of the ActivityPub ecosystem right now: <a href="https://spritely.institute/" rel="nofollow">https://spritely.institute/</a><p>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.
Seems very similar in goal to the Solid Project, <a href="https://solidproject.org" rel="nofollow">https://solidproject.org</a>, which Tim Berners Lee is involved with and is being standardized by the W3C.
This is an interesting start. I have many questions though:<p>1. Why no public forum or (heavens forfend) a standards body community group, for the spec?<p>2. For the data model, why not use the excellent ActivityStreams2? The actual data model that contains the posts etc (<a href="https://atproto.com/lexicons/bsky-app" rel="nofollow">https://atproto.com/lexicons/bsky-app</a>) is a serious step backwards from the event-log architecture of AS2.<p>3. Why reinvent gRPC/JSON-RPC? Seriously, of /all/ the things to reinvent, why RPC?<p>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!<p>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.<p>A permissionless blockchain does seem like it would be a suitable solution, but your identity page mentions avoiding blockchain due to slow commitment times:<p>> 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)<p>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.
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?<p>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)
An unfortunate name collision.
I thought this was some historical article about AT-commands used to command old phoneline modems.<p>But also appropriated to control modern GSM and LTE chipsets, SCADA radio modems and who knows what else.<p>I hope my search results won't get polluted with this too badly.
This is a solution to Twitter's problems, not a solution that helps users.<p>The crucial question is 'Will Twitter actually adopt it?' - if so, we'll all need to pay attention. If not, it can be safely ignored.
Can anyone explain why Bluesky is making a new protocol instead of using ActivityPub like Mastodon? What advantages would it have over ActivityPub? <a href="https://activitypub.rocks/" rel="nofollow">https://activitypub.rocks/</a> Worth noting that ActivityPub is an official W3C recommended standard.<p>Is it just Not Invented Here syndrome? This could lead to <a href="https://xkcd.com/927/" rel="nofollow">https://xkcd.com/927/</a>
Hmm I don't get it.<p>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).<p>Who is this marketed at?<p>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.<p>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.<p>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.<p>Time will tell how seriously they move forward with this.
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.
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?