Live data from Hacker News

The AT protocol is the most obtuse crock of shit

urbanists.social

461–470 of 493 posts

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

#461

When he was ranting about crypto, I had assumed that Bluesky had done another silly Coin or something. Nope, this is just apparently a dislike of public keys and signing messages, which seems like a great idea for a federated protocol.

Parts of the BlueSky protocol do use stuff designed for "web3" cryptocurrency stuff ( https://www.w3.org/TR/did-core/ ), but there's no cryptocurrency in use for the AT protocol. I'm not sure why they're even using this because the docs state that the current DID stuff is all placeholders until they can find something better.

> I'm not sure why they're even using this because the docs state that the current DID stuff is all placeholders until they can find something better.

DID is there to stay, it's that the DID spec has a concept called "verification methods" https://www.w3.org/TR/did-core/#verification-methods. They are providing a verification method called "DID Placeholder (did:plc)", because none of the existing methods suited their goals. The idea is that if and when a better verification method appears, they can move to that, but that doesn't mean abandoning DIDs altogether.

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

#462
post #341

Earlier quoted context omitted.

It's weird to me that all the complaints about @proto being NIH focus on ActivityPub when if anything it's closer to an evolution of secure scuttlebutt. The two are so fundamentally different I do not understand the complaints.

Bluesky is a Twitter-like platform like Mastodon, so the comparison makes sense if you look at the primary implementations. SSB is also decentralised, while ATProto is federated - like ActivityPub.

User Identity in ATProto is decentralized, it's meant to use W3C DIDs.

That's actually one of the things that bugs me about ActivityPub... unless I'm running my own one-single-user instance I won't have control over my own identity.

It's also very weird how even on a supposedly "federated" system the only way to ensure you can access content from all instances (even if they differ in philosophy or are on opposite sides of some "inter-instance-war") is to have separate accounts for each side... it kind of defeats the point of federation. There's even places like lemmy which instead of using blocklists use allowlists, so they will only federate with pre-approved instances.

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

#463
post #398
post #385

Earlier quoted context omitted.

Even framing it as 'account portability' is missing the point. I want to own my identity and take it with me anywhere. I shouldn't need to transfer anything, its mine. This model is fundamentally incompatible with how ActivityPub works (no, running your own server is not the same thing as decoupling identity from the concept of a server itself.) Could that change in the future? Maybe, but not without prior art. Even…

It's not incompatible with how ActivityPub works at all. The ActivityPub spec says that object id's should be https URI's, not that they must . The underlying ActivityStreams spec just requires them to be unique. All that's needed to provide full portability without a "transfer" is for an implementation to use URI's to e.g. DID's, or any other distributed URI scheme. Optionally, if you want full backwards compatibili…

> the main challenge there is not the spec but getting buying from at least Mastodon

Which is why promoting a new competing and incompatible protocol is a good way to push for change.

You want Microsoft to become more open? Then start promoting a pure FLOSS alternative until they can't ignore it anymore.

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

#464
post #233

Earlier quoted context omitted.

> The schema is a well-defined machine language which translates to static types and runtime validation through code generation. Can you elaborate on this point? There's multiple mature solutions in this space like OpenAPI+Json Schema, GraphQL, gRPC. All try to solve the same problems to varying degrees and provide similar benefits like generated static typed and runtime validation. Was there something unique for you…

I don't know what AT is doing but I can say that while JSON Schema is okay as a validation schema it is less okay as codegen schema. I don't know if there is a fundamental divide between these two uses but in JSON Schema there is definitely an impedance mismatch. For example, the JSON Schema structures: `anyOf`, `oneOf` and `allOf` are fairly clear when applied toward validation. But how do you map these to generatin…

There's indeed few languages that can model all of JSON Schema in their type system. Typescript comes close. However, you can just use a subset as you said.

I don't really understand why this is a problem. Unless you're using things like Haskell, Julia, or Shapeless Scala, you generally accept that not everything is modeled at the type level. I don't know the nuances of the C++ types you mentioned, but I have not encountered the ambiguity you described in Typescript or the JVM. E.g. JSON Schema is pretty clear on that any object can contain additional unspecified keys (std::map I assume) unless additionalProperties: false is specified.

> `anyOf`, `oneOf` and `allOf` for [...] C++ data structures?

Like I said I don't know C++ well enough, but these have clear translations in type theory which are supported by multiple languages.I don't know if C++ types are powerful enough to express this.

allOf is an intersection type and anyOf is an union type. oneOf is challenging, but usually modelled OK enough as an union type.

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

#465

Earlier quoted context omitted.

> If you're going to go NIH your replacement needs to not just be better but substantially better, and you should also show understanding of the original open spec. I just disagree with this in principle. I wonder what the tech equivalent of "laissez faire" would be. To this day I don't understand how anyone in the tech world thinks they can make a single demand of anyone else. Even as a customer I believe you can re…

> I don't understand how anyone in the tech world thinks they can make a single demand of anyone else. Ultimately, yes you're right, no-one can make actual "demands" of anyone else. My language above is demanding, certainly, but ultimately I'm just arguing opinion. I cannot control any outcomes of what Bluesky or any other enterprise choose to pursue. > What is it about this specific area of the web that attracts the…

> I think it stems from the unprecedented success of such zealots in the 1980s,

I would challenge this belief, that the success of Linux, or the Web technologies (TCP, HTTP, HTML, etc.) were primarily the result of the zealots from the 80s. I would challenge the belief that protocols for Twitter-like communication fall into the same category as things like POSIX, TCP/IP, HTTP, HTML, etc.

> That's largely been the result of people arguing passionately on the internet to advocate for that level of openness, collab & interop.

My own opinion is the key to success was a large number of people writing useful code and an even larger number of people using that code.

One example that comes to mind is how HTML was spun out from w3c into WhatWG. Controversial at the time to say the least but IMO necessary to get away from the bickering of semantic web folks who were grinding the progress to a halt. HTML 5 won the day over XHTML (actually to my disappointment). The reason wasn't the impassioned arguments of the semantic web zealots, it was the working implementations delivered by the WhatWG members to serve the literal millions of people using their applications. Another example is the success of Linux over Hurd - the latter being a technology initially supported by the most vocal and ideological of all the zealots.

It is a simple fact that if AT garners sufficiently useful implementations and those implementations garner sufficient numbers of users - all of the impassioned arguments against it will have been for naught. So those arguing should probably stop so that they can focus on implementing ActivityPub (or whatever they think is best) and attracting users. I guarantee you that if ActivityPub attracts millions of users then Bluesky will suddenly see the light. They will change course just like every big tech company did when Linux became successful.

It is also why I think all of the hot-air on RSS and Atom was literally wasted. As technologies both have thus-far failed to attract enough users to make it worth it. I would bet that the same will be true of both AT and ActivityPub. Unless someone develops an application that uses one or the other and it manages to attract as many users as Twitter then people are just wasting time for nothing.

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

#466

Earlier quoted context omitted.

Something that I think your analysis is missing is that with a decentralized product, ops is also user experience. The whole point is that it needs to be reasonably easy for people to run and scale their own servers. If people are constantly being burned out, quit, or run out of money, then it has an impact on regular users.

Assuming you have meaningful data that shows that, instead of handwavy conjecture, sure. I don't think most projects do ;)

What I’m saying is that server admins should be considered users as well. That’s not something that needs to be driven by data.

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

#467
post #418

Earlier quoted context omitted.

...and now you have to track which instance is authorize to block which hash, creating a lot of extra complexity. Plus, we need to trust all instances to really delete stuff. It makes life really easy for spammers.

[flagged]

Please edit out swipes from your HN comments, as the guidelines ask: https://news.ycombinator.com/newsguidelines.html.

Your comment would be fine without that first bit.

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

#468
post #411

Earlier quoted context omitted.

There can be an interrogation endpoint/message of supported versions/extensions to the base protocol, that's a very normal thing. If it supports bundled delivery, send a single bundle if not send them all individually.

Yep, And I'm sure there are some instances that do exactly that. But in a distributed protocol you only get the benefit if both sides of a given interaction support the optimization. For something in the spec that is optional you can't rely on it and you aren't forced to implement it so it's not irrational to just ignore it. Which typically means you only get occasional marginal benefit.

i mean it depends. The vast majority of fedi traffic is mastodon. Add it to mastodon it makes an impression and a real difference. At first mastodon to mastodon comms, but others will take notice, it will find it's way into libraries then it's smooth sailing.

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

#469
post #427

Earlier quoted context omitted.

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

> 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 […], almost always vastly dwarfs all improvement that occurs as a result. So, why is the Fedi not built on RSS/Websub/etc. then?

https://xkcd.com/927/

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

#470
post #411

Earlier quoted context omitted.

There can be an interrogation endpoint/message of supported versions/extensions to the base protocol, that's a very normal thing. If it supports bundled delivery, send a single bundle if not send them all individually.

Yep, And I'm sure there are some instances that do exactly that. But in a distributed protocol you only get the benefit if both sides of a given interaction support the optimization. For something in the spec that is optional you can't rely on it and you aren't forced to implement it so it's not irrational to just ignore it. Which typically means you only get occasional marginal benefit.

> Which typically means you only get occasional marginal benefit.

Which is why most browser-server communitcation is still limited by HTTP/1.0.

Except it isn't. That's not how this works out when there are benefits to all participants to implement these optimizations.

Post reply on HN