(Though I might still waste that saved click just to see what TFA is about...)
<click>
Is it just Not Invented Here syndrome? This could lead to https://xkcd.com/927/
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.
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
https://www.rfwireless-world.com/Terminology/modem-AT-comman...
+++ATH0
ATDT@;684-767-2676 (or any 767-XXXX, 555-XXXX is also fun)
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.
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.
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
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.
And that's not even getting into "oh, ok, so my cousin is going to create his own DNS entry, is he?" https://atproto.com/guides/identity#identifiers
https://atproto.com/lexicons/atproto-com#comatprotocreateses... seems to be missing any 2FA parts, spitting in the face of years of "don't get phished" learning
+++
ATH
I'll definitely bookmark this.
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.
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.
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.
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.
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...
+++
ATH
