[flagged]
The AT protocol is the most obtuse crock of shit
251–260 of 493 posts
Re: The AT protocol is the most obtuse crock of shit
#252Earlier 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.
It's a cheeky way to say @ protocol.
Maybe they could call it the Strudel protocol?
Re: The AT protocol is the most obtuse crock of shit
#253Earlier quoted context omitted.
I think this is referring to the content-hashed user posts. Using this model one can pull content from _anywhere_ without having to worry about MITM forgeries etc. This opens up the structure of the network, basically decentralizing it even _more_. Correct me if I'm wrong on this though.
> Using this model one can pull content from _anywhere_ without having to worry about MITM forgeries etc Does that makes it more difficult to implement the right to be forgotten and block spam and trolls?
Doesn't it make it easier? A list of hashes which should be blacklisted means servers obeying rulings are never at risk of returning that data (this would also work offensively: poll for forbidden hashes and see who responds).
Re: The AT protocol is the most obtuse crock of shit
#254Earlier quoted context omitted.
The URI is expected to be immutable. The URI can be used as a key. Whether the object is depends on the type of object. A hash over the content can not directly be used that way, but it can e.g be used to derive an original URI in a way that allows for predictable lookups without necessarily having access to the origin server. Posts are explicitly not immutable, so they do need to be revalidated, and that's fine. For…
> Posts are explicitly not immutable, so they do need to be revalidated, and that's fine. OK that's my point. In the AT protocol design the data backing posts is immutable. This makes sync, and especially caching a lot easier to make correct and robust because you never need to worry about revalidation at any level. > People want to be able to edit, and delete Immutable in this context just means the data blocks are…
But to model mutable things over and immutable blocks you need to revalidate which blocks are still valid.
You need to know that the user expects you to now have a different view. That you're not mutating individual blocks but replacing them has little practical value.
It'd be nice to implement a mechanism that made it easier to validate whole collections of ActivityPub objects in one go, but that just requires adding hashes to collections so you don't need to validate individual objects. Nothing in ActivityPub precludes an implementation from adding an optional mechanism for doing that the same way e.g. Remote storage does (JSON-LD directories equivalent to the JSON-LD collections in ActivityPub, with Etags at collection level required to change if subordinate objects do).
Re: The AT protocol is the most obtuse crock of shit
#255Okay 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.
So anything later than 1981 is wisdomless?
Re: The AT protocol is the most obtuse crock of shit
#256There was no reason for that toot to be that aggressive :(
The tone of that whole thread in combination with posts like > 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. doesn't make this person seem particularly competent. I'm getting a vague feeling that this is normal discourse on Mastodon though, and that not using social media much shifts your personal overton wind…
On your last point, I think the key distinction is the number of people in the social circle.
On Twitter, it was the entire world. And if you wanted to hold the conch shell, you did what the algorithm wanted which was OUTRAGE.
On Mastodon, it's theoretically scoped down to just your server and a handful of deliberate federations. This exists. You can find these servers and have a BBS-like experience. Tooters give you the time of day and assholes are shown the door.
The Very Online folks, however, use Mastodon differently. For them it's more like "I'll build my own Twitter!" And what they want is more OUTRAGE feed to tap into 20 times a day, but with them in control of the algorithm. So they federate freely, with very large servers, making no material progress on the thing that makes Twitter unhealthy.
The fact that Mastodon can seemingly be used both ways is a good accomplishment. It's not the technology's fault the second use-case is socially toxic. But it does make it very hard to talk about Mastodon because you don't immediately know which way anyone is using it.
Re: The AT protocol is the most obtuse crock of shit
#257Earlier quoted context omitted.
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.
So anything later than 1981 is wisdomless?
ATH
Re: The AT protocol is the most obtuse crock of shit
#258Okay 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 thought exactly the same. I will dive into configuring a Raspberry Pi to work with a 5G hat/SIM and will use at commands for this (first time ever). I was looking forward to reading how horrible an experience it will be and was a bit confused :D
Re: The AT protocol is the most obtuse crock of shit
#259[flagged]
“Twitter outrage” is found anywhere humans are found.
I think people just really wanted to believe that it was Twitter-based because then 1) it’s someone else’s fault (Twitter, not human nature), and 2) it can be magically fixed by leaving.
Re: The AT protocol is the most obtuse crock of shit
#260Earlier quoted context omitted.
Having done a decent bit of hacking around ActivityPub, when I read the (thin, which 'pfraze and others have copped to) documentation I immediately went "oh, this is going to be way more scalable than ActivityPub once it's done." It's not all roses. I'm not sold on lexicons and xrpc, but that's probably because I am up to my eyeballs in JSON Schema and OpenAPI on a daily basis and my experience and my existing toolki…
If they'd proposed (or even just implemented) improvements that at least suggested they'd considered existing options and wanted to try to maximise the ability to do interop (even with proxies), I'd have been more sympathetic. But AT to mean seems to be a big ball of Not Invented Here that makes me worry that either they didn't care and try, or that they choice to make interop worse for a non-technical reason.
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. Multiple protocols can access the same data store. Adopting one protocol doesn't preclude other protocols. I believe Developers should adopt all the protocols.