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

321–330 of 493 posts

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

#321

Post by detourdog »

vidarh wrote: post #312
detourdog wrote: post #260

Earlier quoted context omitted.

During this stage of discovery I'm completely comfortable with ground up rethinks. I don't feel we have the correct solution and there is no commercial reason to ge this thing shipped. Now is the time to explore all the possibilities. Once we have explored the problem space we should graft the best bits together for a final solution, if needed. I'm not sure I see the value of standardizing on a single protocol. Multi…

Ground up rethinks that takes into account whether or not there's an actual reason to make a change is good. Ground up rethinks that throws things away for the sake of throwing them away even what they end up doing would layer cleanly are not. They're at best lazy. At worst intentional attempts at diluting effort. I'm hoping they've only been lazy.

I'm not disagreeing. To say that there is only one way or to project presumed goals and intentions is too far for me.

I firmly believe that protocols are developed through vigorous rewrites and aren't nearly as important as the data-stores they provide access to. I would like our data-stores to be stagnant and as required we develop protocols. Figuring out a method to deal with whatever the hosted data-store's chosen protocol is seems correct to me. I just don't see mutual exclusivity. Consider the power of supporting both protocols.

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

#322

Post by vidarh »

lucideer wrote: post #291
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…

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…

This is a great summary of what my concerns are as well. I'd maybe add one more point:

* Improvements that'd layer cleanly on top of ActivityPub if they'd made any attempt at all.

E.g. being able to "cheaply" ensure that you have a current view of all a given users objects is not covered in ActivityPub - you're expected to basically want to get the current state of one specific object, because most of the time that is what you'll want.

So maybe it falls in the "highly debatable" category, but we also have a trivial existing solution from another open spec: RemoteStorage mandates etag's where a parent "directory" object's etag will change if a contained object changes, and embeds that in a JSON-LD collection as the directory listings. If you feel strongly that this is needed to be able to rapidly sync changes to a large collection, an ActivityPub implementation can just support that mechanism without any spec changes being needed at all (but documenting it in case other implementations wants to do so would be nice). Heck, you can "just" add minimal RemoteStorage compatibility to your ActivityPub implementation, since that too users Webfinger, and exposing your posts as objects in a RemoteStorage share would be easy enough.

Want to do a purely "pull" based ActivityPub version the way AT is "pull"? Support the above (w/fallback of assuming every object may have changed if you care about interop), make your "inbox" endpoints do nothing and tell people you've added an attribute to the actor objects to indicate you prefer to pull and so to not push to you.

Upside is, if any of the AT functionality turns out to be worthwhile, it'll be trivial to "steal" the good bits without dropping interop.

(Also, I wanted to see exactly how AT did pulls, and looked at the AT Proto spec, and now I fully concur with the title of this article)

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

#323

Post by dudeinjapan »

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…

My two cents to the author: make an open-source reference implementation of your own protocol.

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

#324

Post by patchtopic »

sgtnoodle wrote: post #183
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…

Not having read the article, I got pretty far into your second paragraph before realizing you all aren't talking about configuring a modem over a serial link. It's funny because the "Hayes AT command set" protocol is also an obtuse crock. I was really hoping you were going to open my mind with some deep wisdom straight out of 1981.

I assumed Hayes AT at first as well.

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

#325

Post by ymolodtsov »

epicsponge wrote: post #64
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…

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…

> 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.

I literally read about a case over a month ago where some obscure Mastodon-server admin blocked someone's account on their server so it was impossible to move to another instance. The motivation was "I don't want capitalist here, can change my mind for money" (slightly paraphrasing). Basically, it's stupid to use any Mastodon instance other than the few largest one or your own.

That's why BlueSky's approach makes sense.

>with the rest of the federated Internet. You're saying like it's a thing that won and not a niche project for <10M users globally.

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

#326

Post by capableweb »

codetrotter wrote: post #109
capableweb wrote: post #16

Earlier quoted context omitted.

Rebasing and similar operations are only a hassle because multiple authors can edit the same files, so you end up with conflicts. In the scenario where every authors can only change their own files, you can avoid those sort of conflicts, as they'll never happen. Remaining is how to solve files referencing other files (in the case of a federated social media, posts that are replies to other posts) which are way easier…

> every authors can only change their own files, you can avoid those sort of conflicts, as they'll never happen A single author can still run into these issues with git if they use multiple devices. Can the same happen in this social media network for a user that uses the same account on their phone, their tablet and their computers?

> A single author can still run into these issues with git if they use multiple devices.

No, using multiple devices are fine, as long as you're not editing the same content in two different ways on them. Meaning changing "A B" to "A C" on one device, and to "A D" on the other.

> Can the same happen in this social media network for a user that uses the same account on their phone, their tablet and their computers?

When using AT protocol, you'd still be connected to the same PDS, so no conflicts. The conflicts mentioned earlier are about serverserver federation, not serverclient communication.

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

#327

Post by runlaszlorun »

sgtnoodle wrote: post #183
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…

Not having read the article, I got pretty far into your second paragraph before realizing you all aren't talking about configuring a modem over a serial link. It's funny because the "Hayes AT command set" protocol is also an obtuse crock. I was really hoping you were going to open my mind with some deep wisdom straight out of 1981.

Hahaha… I clicked thinking the same. I was ready for a good rant on Hayes modem commands… :)

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

#330

Post by BlueTemplar »

philipwhiuk wrote: post #295
pavlov wrote: post #198

Earlier quoted context omitted.

In this hypothetical minimalist Twitter clone in the 2009 spirit, images are elsewhere. We have a widely used hypertext protocol that lets you reference media objects from anywhere, so let’s use that. Client apps can individually solve the image upload usability question in ways that fit their user base. Yes, there will be broken links. But IMO that’s better than having all your data in one centralized location where…

Deep linking Flickr's content without showing Flickr's adverts gets you blacklisted so quick.

Also YouTube. That was before Twitter betrayed (?) third-party developers around 2013 :

https://www.theverge.com/2012/7/9/3135406/twitter-api-open-c...

For instance it was basically the end of Flattr 1.0 :

https://venturebeat.com/social/flattr-the-crowdfunding-payme...

Post reply on HN