I don’t know anything about XRPC and Lexicon, but claiming that OpenAPI is better than them because it’s more flexible, is not a great argument.
OpenAPI is a very complex spec, and most of the tooling around it, only supports some subset of it.
Sure it’s complex for a reason, it’s design goals are to be able to document the wide array of ways that HTTP APIs can be built, but if you don’t need that complexity, it absolutely makes sense to use a simpler RPC spec.
The AT protocol is the most obtuse crock of shit
151–160 of 493 posts
Re: The AT protocol is the most obtuse crock of shit
#152Okay 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 t…
The notion that server disappearance is a non-issue is quite misleading. Servers go offline for various reasons, such as technical difficulties, financial constraints, or legal issues. Recovering and transferring data without relying on the original server is essential for users to maintain control over their data and identities. DIDs and recovery keys provide a valuable solution to this problem, ensuring user autonomy.
Your reply fails to address that push-based systems are prone to overwhelming home servers due to burst loads when content becomes viral. By implementing pull-based federation, the AT Protocol allows for a more balanced and efficient distribution of resources, making self-hosting more affordable and sustainable in the long run.
Re: The AT protocol is the most obtuse crock of shit
#153Seems like Mastodon/ActivityPub and AT Protocol are solving for opposing problems. Maybe the compromise is a centralized service?
> Maybe the compromise is a centralized service?
Yes.
Centralization is inevitable and normal users only care if they can use it easily or not and don’t have to choose a instance or set up their own mail server, instance, or whatever.
As always with typical techies, the emotions put into this post were already running high given Bluesky itself has gotten someone extremely angry over the tiniest things.
Re: The AT protocol is the most obtuse crock of shit
#154Okay 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 t…
Email has only solved the "authenticity problem" by centralizing to a tiny number of megaproviders with privileged trusted relationships. Forestalling that sort of "solution" seems to me one of the Blueksy team's design goals.
Servers go down or get flaky all the time for various reasons. Easy relocation (with no loss of content & relationships) and signed content (that remains readable/verifiable even through server bounciness) soften the frustrations.
55k tweets is little challenge to replicate, just like 50k signatures is little challenge to verify, here in the 2020s.
If Mastodon does everything better with a head start, it should have no problem continuing to serve its users, and new ones.
Alas, even just the Mastodon et al community emphasis on extreme limits on visibility & distribution – by personal preferences, by idiosyncratic server-to-server discourse standards, by sysop grudges, whatever – suppress a lot of the 'sizzle' that initially brought people to Twitter.
Bluesky having an even slightly greater tilt towards wider distribution, easier search, and relationships that can outlive server drama may attract some users who'd never be satisfied by Mastodon's twisty little warrens & handcrafted patterns-of-trust.
There's room for multiple approaches, different strokes for different folks.
Re: The AT protocol is the most obtuse crock of shit
#155Earlier quoted context omitted.
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 t…
> 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. This has actually happened. It's a real problem. For example, "Mastodon instance mstdn.plus with over 4K users suddenly broke" https://lapcatsoftware.com/articles/mastodon.html As far as I'm concerned, the Mastodon Server Covenant…
I came here to day this.
Another example: Mastodon.lol, which had 12,000 users literally shutdown a few hours ago. They did manage to give notice but the point remains that people had to move instances, cannot take their posts with them, and it’s a giant PITA, server covenant or not.
To call this stuff a “non-issue” seems incredibly obtuse, especially when the data portability piece is clearly an after thought by the Mastodon devs, and something that ActivityPub would need some major changes to get accomplished. Changes that the project leads have been fairly against implementing.
Re: The AT protocol is the most obtuse crock of shit
#156It 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 b…
As far as I can tell ActivityPub is (at least part of) the problem. If it’s not, then Mastodon is simply not trying to be a “Twitter replacement” or a useful global social network at all.
The only worse idea than Bluesky using ActivityPub would be to build something new making all the same design decisions.
Deciding “ActivityPub is the standard” (seriously?!) and demanding we give up already is the opposite of what we need.
I don’t know if AT is the best long term solution, but — and I’ve tried it multiple times — ActivityPub/Mastodon sure as hell isn’t. There’s no value in being interoperable with it that I can see, beyond the potential short term boost to vanity metrics on user numbers.
I absolutely want my identity to use public key cryptography, and I absolutely want to store all my emails, tweets (or whatever), and DMs locally first. I don’t like how accounts and servers work in Mastodon and the federation and global discovery approach sucks too.
The best thing we can do now is keep an open mind and try as many approaches as possible, because if something better than ActivityPub doesn’t come along society is stuck with centralised social media forever.
Re: The AT protocol is the most obtuse crock of shit
#157Okay 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 t…
> Mastodon also changed their app to use Mastodon.Social as the default server, so this is a non-issue.
They have instead created another issue.
Before, it was a usability issue which normal users looking for an alternative social network got confused on the sign up process and gave up.
If that wasn’t an issue why did the Mastodon devs decide to select a default server in the app after seeing this?
Now, they have traded that off and created a centralization issue going against the point of encouraging federation.
This only shows that centralization wins in the end.
Re: The AT protocol is the most obtuse crock of shit
#158Earlier quoted context omitted.
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 t…
> Email had this exact same problem, yet was able to build protocols on top of it in order to fix the authenticity problem. On the contrary, email has no solution to the authenticity problem that’s being talked about. Even what there is is a right mess and not even slightly how you would choose to build such a thing deliberately. If you want to verify authenticity via SPF/DKIM/DMARC, you have to query DNS on the send…
I think they're talking about GPG, not SPF/DKIM/DMARC.
Which is a risky thing to do, because most people don't associate GPG with positive feelings about well designed solutions, but they're right in that it works well, solves the problem and is built squarely on top of email.
The reason that it's not generally well received is that there's no good social network for distributing the keys, and no popular clients integrate it transparently.
Re: The AT protocol is the most obtuse crock of shit
#159> "Imagine if I had to store the 50k+ tweets I've made on Twitter on my device, and upload ALL of them to a new server whenever a community server went down."
This... doesn't seem too bad at all?
Let's assume an average of 150 bytes of text per tweet, and an additional 50 bytes of actually important metadata. That's only 10 megabytes for the entire archive of 50,000 items. A single HDR photo from a modern smartphone is larger.
IMO this was the original point of Twitter: the extreme limitation on post size (140 characters) made it feasible to build applications that work with large amounts of content. There was a time around 2010 when building a Twitter API client was the standard demo for a new UI framework — the data model was simple enough that a basic client was the next step up from "Hello world" complexity.
This was actually a nice vision for a social network! Lots of simple near-realtime data, a jungle of interesting clients to make sense of it. I wish someone was building a Twitter competitor with this kind of minimalist approach.
Re: The AT protocol is the most obtuse crock of shit
#160> I was like "I'll just make a simple alternative to the BlueSky server in Elixir". But it CAN'T be a simple implementation like ActivityPub can be, because it is extraordinarily complex and requires you to make guarantees about your storage and how your application works.
You might suspect that OP has a familiarity bias here but actually there is objective evidence that ActivityPub based implementations are (relatively) simple: there are dozens of implementations of both servers and clients, will all sorts of functionality that is not emulating the "twitter/mastodon" experience. Heck, even a Wordpress plugin in the works.
How well all these things will scale etc. is still somewhat of a question mark but this aspect feels important beyond specific details and choices. The simpler, more generic an approach, the more likely it is to find fertile ground and grow as a decentralized architecture. The original decentralized Web was simple and generic and this has been touted as key factor for its explosive adoption.
In a sense this was also its ultimate downfall: it did not provide (out of the box) the tools to build the connectivity / social graph experience that was so enormously desirable (and was not provided e.g., by RSS). ActivityPub is somehow making up for that original gap. There might be other ways to do this. But unless there is a bigger agenda (commercialization, financialization), gratuitous complexity driven by not-invented-here or desire for centralized control is more likely to hinder than help.