Also came here to read about AT modem commands. Still have no idea (and admittedly little interest) what this other nonsense is... Did it have to use the existing name? Did the authors not have access to a search engine?
The AT protocol is the most obtuse crock of shit
61–70 of 493 posts
Re: The AT protocol is the most obtuse crock of shit
#62I'm glad somebody looked, because basics like when messages are actually passed around is something I didn't see in the atproto docs either. Alice on server X follows Bob on server Y. When are Bob's posts delivered to X such that Alice may see them? Are they pushed from Y? Are they pulled by X? Polling seems like an absolute disaster in an environment where people have an expectation of semi real-time communication.
The post alleges Bluesky pull based, which would imply it's like RSS but with signatures: > It uses pull-based federation instead of push-based like Mastodon. I was hoping they would employ both: push and pull. Some scenarios I could imagine pull being more efficient, and sometimes push. For instance if I run my own server I don't need to be pushed all content when I sleep. However when I return it could do pulls and…
There are likely scenarios where some level of push-based comms will be necessary, as I understand it. Direct messaging, for example, seems like it'll require pinging a server to pull an asymmetrically encrypted message, or similar.
Re: The AT protocol is the most obtuse crock of shit
#63I'm amused. First, that it's the AT protocol... I thought someone was getting pissy about their 45 yr old vintage 1200 baud modem. Second, that people are discovering that Twitter 2.Oh isn't truly federated but just pretends to be. The open source community's spent how many years designing a non-proprietary protocol and putting out reference implementations (and extending it to Facebook-like and Youtube-like and Word…
> The open source community's spent how many years designing a non-proprietary protocol and putting out reference implementations (and extending it to Facebook-like and Youtube-like and Wordpress-like offerings)...
And it's awkward to write code for and the people who inhabit it range from right-wing reactionaries to, as was so effectively put, the homeowners' association. Turns out that people don't care about "open source" unless it's easy to work with and people especially don't care about "open source" when they want to talk and shitpost with their extended friend group. (Which no, Mastodon doesn't do a good job of! Even setting aside that quote-toots are Good, Actually, Mastodon doesn't let me see replies to a toot unless I go digging so I don't know if I'm just being one of another set of replies that might already have said what I was going to say, so why post at all?)
I tend to think that the Bluesky crowd seems like they have their shit together as well as having a small beta explode can allow it (the web app is literally at `staging.bsky.app`, come on) and I think the AT Protocol docs identify real and probably intractable shortcomings in ActivityPub. But it doesn't somehow render ActivityPub moot if you want to use it. Go for it. It's still there.
Re: The AT protocol is the most obtuse crock of shit
#64Okay well. I work on Bluesky and helped build the AT Protocol. I'm sorry Sam differs with us on this, and I'm glad that Activity Pub is already there for him. However, Sam doesn't understand the ATProto very well and I want to clear it up a bit. Before I do, let me just say: Bluesky and the AT Proto are in beta. The stuff that seems incomplete or poorly documented is incomplete and poorly documented. Everything has m…
Hi, original author here. Some comments:
> We sign the records so that authenticity can be determined without polling the home server, and we use a repository structure rather than signing individual records so that we can establish whether a record has been deleted (signature revocation).
Why do you need an entirely separate protocol to do this? Email had this exact same problem, yet was able to build protocols on top of it in order to fix the authenticity problem. This is the issue: instead of using ActivityPub, which is simpler to implement, more generic, and significantly easier for developers to understand, you invented an overly-complex alternative that doesn't work with the rest of the federated Internet.
> The schema is a well-defined machine language which translates to static types and runtime validation through code generation. It helps us maintain correctness when coordinating across multiple servers that span orgs, and any protocol that doesn't have one is informally speccing its logic across multiple codebases and non-machine-readable specs.
OpenAPI specs already exist and do the same job. They support much more tooling and are much easier for developers to understand. There is objectively no reason why you could not have used them, you are literally just making GET and POST requests with XRPC. If you really wanted to you could've used GraphQL.
There are plenty of protocols which do not include machine-readable specs (including TCP, IP, and HTTP) that are incredibly reliable and work just fine. If you make the protocol simple to understand and easy to implement, you really don't need this (watch Simple Made Easy by Rich Hickey).
> The DID system uses the recovery key to move from one server to another without coordinating with the server (ie because it suddenly disappeared).
Why is this necessary? The likelihood of a server just randomly disappearing is incredibly low. There are community standards and things like the Mastodon Server Covenant that make this essentially a non-issue. You're storing all of a user's post history on their own device in the case of an immediate outage. That's equivalent to Gmail storing all of your emails on your device in case you want to immediately pack up and move to another email provider. That is an extremely high cost (I have 55k tweets, that would be a nightmare to host locally) for an outcome that is very unlikely.
> It supports key rotations and it enables very low friction moves between servers without any loss of past activity or data.
This forces community servers to store even more data, data that may not even be relevant or useful. Folks might have gigabytes of attachments and hundreds of thousands of tweets. That is not a fast or easy thing to import if you're hosting a community server. This stacks the decks against community servers.
Most people want some of their content archived, not all, and there is no reason why archival can be separate from where content is posted. Those can be two separate problems.
> That design is why we felt comfortable just defaulting to our hosting service; because we made it easy to switch off after the fact if/when you learn there's a better option. Given that the number one gripe about activitypub's onboarding is server selection, I think we made the right call.
Mastodon is able to do this on top of ActivityPub. Pleroma works with it. Akkoma works with it. There's already a standard for this. Why are you inventing an unnecessary one?
Mastodon also changed their app to use Mastodon.Social as the default server, so this is a non-issue.
Re: The AT protocol is the most obtuse crock of shit
#65A bit difficult to take anything seriously that this hyperventilating dweeb says:
> But I think what's key is to keep an anticapitalist mindset. We can make things easier for users without allowing in what makes social media so fucking awful: capitalism.
Re: The AT protocol is the most obtuse crock of shit
#66It seems to me that a lot of the problems discussed in this thread (it's using a new protocol that doesn't work with existing tools, it uses crypto, handles auth in the protocol, server can goes down) are just frustrations that don't have to do with the core innovation that Bluesky promises to deliver, and are instead confusing the AT protocol to be another ActivityPub-related protocol, rather than something complete…
> are just frustrations that don't have to do with the core innovation that Bluesky promises to deliver, and are instead confusing the AT protocol to be another ActivityPub-related protocol, rather than something completely different.
AtProto is designed to be a federated protocol. The issue I have is that it is not interoperable with the major standard used on the federated internet right now: ActivityPub. You can built protocols on top of each other. Instead of doing that, Bluesky built a confusing alternative that is difficult to implement and difficult to work with.
> In fact, it misses that having pull-based indexes is part of the idea of separating data publication vs. data curation.
Mastodon does this already. There is literally an 'explore' part of the app that is completely separate from the feed and does not rely on ActivityPub.
You cannot 'publish' content without having some sort of a federation protocol to go overtop of it, to network things together and send your content to the people who follow you. There is nothing about ActivityPub that makes a single global view impossible or hard to implement.
Re: The AT protocol is the most obtuse crock of shit
#67> I think the fundamental reason why we keep seeing more and more bullshit protocols and projects pop up like this is one fundamental mindset: a refusal to attribute the problems of the modern internet solely to capitalism. I mean, I'm sure they have some points in this ranty thread of toots, but it's hard to take it serious when it ends up blaming it all on capitalism (which, I hear you brother, I'm no fan either) a…
> If I'm getting anything wrong, it's the fault of the Bluesky authors
I dunno, this seemed an entirely on-message thing for a “literal communist” to say.
Re: The AT protocol is the most obtuse crock of shit
#68It seems to me that a lot of the problems discussed in this thread (it's using a new protocol that doesn't work with existing tools, it uses crypto, handles auth in the protocol, server can goes down) are just frustrations that don't have to do with the core innovation that Bluesky promises to deliver, and are instead confusing the AT protocol to be another ActivityPub-related protocol, rather than something complete…
The DID method has to satisfy a lot of requirements. I did a ton of research on DHT and blockchain approaches and none of them give the right performance, reliability, and cost outcomes while also supporting key rotation. DNS isn't far off but it's a little obtuse to cram it into, so we're starting with did:web and did:plc. We'll add others if they have the right characteristics. The only options that seem reasonable…
Since you're familiar with this, what was wrong with how Farcaster approached name registration? Signing up or rotating your key is (relatively) cheap on Ethereum mainnet, and client apps could front the cost of signing users up. The user registry doesn't need to be maintained by a closed group in the long run (could start out that way, with Bluesky maintaining the contracts but eventually removing upgradeability when out of beta).
Re: The AT protocol is the most obtuse crock of shit
#69With all that screaming from a user on the main competing network, I really need to hear a response from the Bluesky team to form an opinion here. And understand better why this guy is so upset about this destined-to-fail network to curse and foam about it.
> With all that screaming from a user on the main competing network Isn't everyone on a "competing" social network before they join Bluesky? I managed to snag an invite (sorry, I don't have any others), so I'm on both at the moment. Though I've found Bluesky to be pretty boring and don't check in much. > And understand better why this guy is so upset about this destined-to-fail network to curse and foam about it. It…
Exactly this, I literally was just trying to implement a simple Elixir server that would scale pretty well. The problem is the protocol is incorrectly spec-ed, is not thought through very well, is incredibly complex and hard to explain, and reinvents the wheel in just about every way it can. This means that in languages like Elixir, which has stuff like an ActivityPub implementation, OpenAPI libraries, and JSON Schema support, you have to write everything from scratch because the user base is smaller than TypeScript / whatever they're writing their implementation in. The protocols they're layering on don't have proper implementations in Elixir, because they're hard to implement right and are annoying to deal with.
Re: The AT protocol is the most obtuse crock of shit
#70I'm amused. First, that it's the AT protocol... I thought someone was getting pissy about their 45 yr old vintage 1200 baud modem. Second, that people are discovering that Twitter 2.Oh isn't truly federated but just pretends to be. The open source community's spent how many years designing a non-proprietary protocol and putting out reference implementations (and extending it to Facebook-like and Youtube-like and Word…
> The open source community's spent how many years designing a non-proprietary protocol and putting out reference implementations (and extending it to Facebook-like and Youtube-like and Wordpress-like offerings)... And it's awkward to write code for and the people who inhabit it range from right-wing reactionaries to, as was so effectively put, the homeowners' association . Turns out that people don't care about "ope…
> and I think the AT Protocol docs identify real and probably intractable shortcomings in ActivityPub
Except that they are objectively wrong about nearly everything they talk about with regard to ActivityPub. Quoting from the FAQ:
> Account portability is the major reason why we chose to build a separate protocol.
There is a widely-accepted account portability protocol built on top of ActivityPub that multiple servers, including Mastodon and Pleroma, all support.
> We consider portability to be crucial because it protects users from sudden bans, server shutdowns, and policy disagreements.
There is nothing inherent about their protocol that solves this. The app on iOS (the Bluesky app) solves this by downloading all tweets locally, which is incredibly space-inefficient and keeps the server from... doing the job of a server (storing that data for you). Additionally, user data is still accessible and downloadable after a suspension on Mastodon and Pleroma.
> Our solution for portability requires both signed data repositories and DIDs, neither of which are easy to retrofit into ActivityPub.
There is quite literally no need for this and they absolutely could have built something that addresses these issues on top of ActivityPub. We're talking about the people who couldn't use OpenAPI, but instead built a shittier version of GraphQL while bold-faced saying 'there was no alternative'.
> a preference for domain usernames over AP’s double-@ email usernames
No need to build a separate protocol for this.
> and the goal of having large scale search and discovery (rather than the hashtag style of discovery that ActivityPub favors).
Nothing about ActivityPub, Mastodon, or the general Fediverse prohibits you from scraping it to make this happen. There are services that do this right now. Mastodon has discovery built into it, this literally completely ignores that.
ActivityPub is the standard for federation on the internet, and for allowing interoperation between social networks. That is the key here. I don't give a shit if people use Mastodon. I myself probably wouldn't use it if I wasn't running a Mastodon server.
What I do care about is whether a service is built on ActivityPub. Even if my friends want to use another social media service (maybe they're on PixelFed or whatever it's called), I can still follow them and interact with them over there while using Mastodon. You cannot do that with Bluesky.
The problems that Bluesky identified with ActivityPub objectively could've been solved by building something on top of ActivityPub, retaining the 'interoperable social network' quality of it. Email had the same problems, and instead of throwing out the email protocol, we built DMARC and co on top of it.
So no, I don't want people to use Mastodon, I don't give a shit about people using Mastodon. I literally criticized Mastodon later on in the thread. What I care about is interoperability, ease of use, and open standards, and AtProto is objectively not that.