Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The AT protocol is the most obtuse crock of shit

urbanists.social

Post reply on HN
Print view View original

351–360 of 493 posts

Re: The AT protocol is the most obtuse crock of shit

#351

Post by linuxdude314 »

im_dario wrote: post #105
rektide wrote: post #3

> It turns out using Git, which is almost always used with a centralized 'remote', to do federation, which needs to be weakly consistent, IS A BAD IDEA!!!!! Given that a user owns their feed, I'm not sure why this is a bad idea? I want to take this critiques here seriously but there's not a ton to grasp onto. It definitely didn't feel great that AtProto built from bare ground, reinvented json-schema & OpenAPI for no…

It doesn’t really use Git, but it has Git semantics. They borrowed some basic concepts (repository, commit, etc).

Exactly.

Anyone worrying about having to rebase, is over thinking it. This is a protocol level detail hidden behind shiny UX elements.

I’ve been using Bluesky for 2 months now; it’s very easy to use.

Re: The AT protocol is the most obtuse crock of shit

#352

Post by mkr-hn »

lucideer wrote: post #335
zaphar wrote: post #320

Earlier quoted context omitted.

I run a single user ActivityPub instance with a minimal following and small number of people across multiple instances that I follow. From a user perspective ActivityPub is fine I have no complaints. However from an Ops perspective ActivityPub is incredibly chatty. If this had to scale to a larger instance the costs would spiral fast. Operationally and cost efficiency wise ATProto is a better looking protocol already…

> ActivityPub is incredibly chatty. > ATProto is a better looking protocol already. Are there benchmarks for this? What's the level of difference here? Request frequency seems closely linked to activity and XRPC bodies are JSON just as ActivityPub so message size should be within order of magnitude at least. Are there architectural differences that reduce request frequency significantly? > If this had to scale to a l…

Sidekiq seems to be the culprit from what I've seen and read from people who've run into this issue. It gets overloaded fast if you don't have enough processing power in front of the queue. Lighter implementations apparently do something different, or are more efficient in handling their queues without whatever overhead Sidekiq adds.

Re: The AT protocol is the most obtuse crock of shit

#353

Post by babel_ »

mkr-hn wrote: post #277
pfraze wrote: post #54

Okay 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…

There's a discourse clash. AT and Bluesky are unfinished. Not ready for primetime. It's not fair to compare it to mature, well-developed stuff with W3C specs and millions of active users on thousands of servers with numerous popular forks. But, also, everyone who hates Mastodon and spent the last months-years complaining about it is treating your project like the promised land that will lead them into the Twitterless…

> It's not fair to compare it to mature, well-developed stuff

Really? So rather than try to compare, contrast, and course-correct a project in its early stages by understanding the priors and alternatives, we should only do retrospectives after it has matured?

I would have thought this was the whole point of planning in early development: figuring out what you actually need to make? And that is usually a relative proposition, a project is rarely in a vacuum!

We should never just uncritically go ahead with the first draft in anything, especially not in the protocols we use, as they have this annoying habit of sticking around once adopted and being very hard to change after the fact.

Re: The AT protocol is the most obtuse crock of shit

#354

Post by DannyBee »

zaphar wrote: post #320
lucideer wrote: post #291

Earlier quoted context omitted.

Reading this I hear someone passionate about technology for the sake of technology. Which is cool, I totally get the desire to build things oneself, but it doesn't really address the substantive questions people are asking about AT: An open protocol exists that broadly does what you want to do. That protocol is stable and widely used. That in itself, regardless of the quality of the protocol, already represents an OK…

I run a single user ActivityPub instance with a minimal following and small number of people across multiple instances that I follow. From a user perspective ActivityPub is fine I have no complaints. However from an Ops perspective ActivityPub is incredibly chatty. If this had to scale to a larger instance the costs would spiral fast. Operationally and cost efficiency wise ATProto is a better looking protocol already…

Being technically better is usually not a good enough reason to be incompatible. I'm not sure why people don't get this, but it is almost always true.

Starting from scratch, just because you can theoretically design a better system, is one of the worst thing to do to users. Theoretically better also rarely wins in the marketplace anyway.

If you want a slightly lighter position: Software needs to be built to be migrated from and to, as a base level requirement. Those communities that do this tend end up with happy users who don't spend lots of toil trying to keep up. This is true regardless of whether the new thing is compatible with the old - if it doesn't take any energy or time, and just works, people care less what you change.

Yes, it is hard. yes, there are choices you make sometimes that burn you down the road. That is 100% guaranteed to happen. So make software that enable change to occur.

The overall the amount of developer toil and waste created en masse by people who think they are making something "better", usually with no before/after data (or at best, small useless metrics sampled from a very small group), almost always vastly dwarfs all improvement that occurs as a result.

If you want to spend time helping developers/users, then understand where they spend their time, not where you spend your time.

Re: The AT protocol is the most obtuse crock of shit

#356

Post by remram »

commoner wrote: post #274
bmacho wrote: post #144

It says To use the Mastodon web application, please enable JavaScript. Alternatively, try one of the native apps for Mastodon for your platform. Good job, Mastodon. (No, I am not the same guys that complain they don't see javascript games or utilities without javascript. But I think I should be able to see a text on the Internet?)

You might want to try Brutaldon, a free and open source Mastodon web client that works without JavaScript. Brutaldon can optionally be self-hosted and it also supports Pleroma. - Brutaldon: https://brutaldon.org - Source: https://gitlab.com/brutaldon/brutaldon

How do you use this to see the above thread?

Re: The AT protocol is the most obtuse crock of shit

#357

Post by nonbirithm »

renahlee wrote: post #59

There was no reason for that toot to be that aggressive :(

It's like a person ranting about a way of building decentralized social media that is currently subpar on a decentralized social media platform so that the people building the new decentralized social media platform can redesign it to be improved such that the ranter can move onto the new social media platform that facilitates him ranting about even more things in a vastly more efficient manner because they listened to his rants and improved the federation protocol.

Re: The AT protocol is the most obtuse crock of shit

#358

Post by lsaferite »

quaintdev wrote: post #212
askvictor wrote: post #196

Earlier quoted context omitted.

Yeah, I wish they hadn't clobbered the name of an existing, well-known protocol. It's still used in drivers for cellular modems (I'm working with it right now), which are getting more and more numerous for IoT applications.

Makes it really hard to search stuff. This has happened with Matrix, Go. Although using golang resolves issue with Go.

I agree that 'go' has to be the worst naming from an SEO perspective. Only ones worse a single letter names. And TBH, they might be _better_ simply because they aren't a common English language word.

Re: The AT protocol is the most obtuse crock of shit

#359

Post by zaphar »

lucideer wrote: post #335
zaphar wrote: post #320

Earlier quoted context omitted.

I run a single user ActivityPub instance with a minimal following and small number of people across multiple instances that I follow. From a user perspective ActivityPub is fine I have no complaints. However from an Ops perspective ActivityPub is incredibly chatty. If this had to scale to a larger instance the costs would spiral fast. Operationally and cost efficiency wise ATProto is a better looking protocol already…

> ActivityPub is incredibly chatty. > ATProto is a better looking protocol already. Are there benchmarks for this? What's the level of difference here? Request frequency seems closely linked to activity and XRPC bodies are JSON just as ActivityPub so message size should be within order of magnitude at least. Are there architectural differences that reduce request frequency significantly? > If this had to scale to a l…

One example of the chattiness is a flow where more than one person is following the same individual on another server. That person will have to push new messages to every single one of the people following them. This means that if 10 users are following me from the same server I will not have 1 push for that instance, I'll gave 10 pushes for the same single unchanged message. This is built into the protocol. That's a lot of throughput for something that could be much much less chatty.

Now on my single instance it's not too bad because 1. I follow maybe 40 people and 2. I have like max 10 followers. For an instance with people with high follower counts across multiple other instances it could get to be a problem fast.

Edit: my previous description used fetch when it should have used push.

Re: The AT protocol is the most obtuse crock of shit

#360

Post by remram »

voytec wrote: post #231

> 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. Twitter had what, 160 or 280 char limit per message? 50k*280 is 14MB. What's to imagine here?

With images often in the megabytes range, and videos an order of magnitude higher, this could be anywhere between 5MB and 100GB.
Post reply on HN