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

211–220 of 493 posts

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

#211

Post by pera »

int_19h wrote: post #164
tsuujin wrote: post #94

Earlier quoted context omitted.

I think it’s important to say this: I think asking questions is great, and I’m glad that we’re not just taking statements at face value because making social suck less is a worthy goal. However, you are coming across as highly adversarial here. Mostly because you immediately follow your questions with assertions, indicating that your questions may be rhetorical rather than genuine. I’m not accusing you of anything pe…

They're explicitly not debating in good faith: "Also I don't care if I'm spreading FUD or if I'm wrong on some of this stuff. I spent an insane amount of time reading the docs and looking at implementation code, moreso than most other people. If I'm getting anything wrong, it's the fault of the Bluesky authors for not having an understandable protocol and for not bothering to document it correctly." ( https://urbanis…

Yeah the way he conflates "crypto" to refer both cryptography and cryptocurrency, and the rhetoric itself is quite odd: https://urbanists.social/@sam/110340265606422596

It's unfortunate because there are some valid points in his criticism.

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

#212

Post by quaintdev »

askvictor wrote: post #196
sgtnoodle wrote: post #183

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

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.

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

#213

Post by detourdog »

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.

Yes, I came for a critique of the Hayes AT commands.

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

#214

Post by lapcat »

pfraze wrote: post #55
lapcat wrote: post #46

> "Additionally, if a Bluesky server goes down, their way of keeping access to your data is by storing all of it on your device!" This seems troubling, if it's accurate. [I've edited the above quote to remove some all-caps and exclamation points.]

You'll store it on your own device, or on another service. I don't understand this criticism; where else do people back up their data?

To avoid repeating myself, see this comment: https://news.ycombinator.com/item?id=35885373

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

#215

Post by asimpletune »

chrismorgan wrote: post #138
epicsponge wrote: post #64

Earlier 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’m curious about this. So email that I’ve sent, let’s say from a gmail account to an iCloud account, isn’t guaranteed to be verifiable years later because of dkim key rotation?

That’s not great. I wonder if the receiver could append a signed message upon receipt with something like “the sender’s identity was valid upon receipt”.

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

#216

Post by magicalhippo »

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.

Indeed. As much as the k-based KDE app names might look or sound silly, they're mostly quite searchable due to being a tad different.

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

#217

Post by doctor_eval »

jeroenhd wrote: post #169
doctor_eval wrote: post #133

Earlier quoted context omitted.

Yea I was like, 50K tweets converted to bytes is like… well it’s one second to upload on my home internet connection. After that, it just felt like rant.

For what it's worth, when a server does go down and thousands of people start uploading their 50k skeets that all need to be cryptographically verified, other major servers will have quite the scaling challenge. Cryptographic verification is intentionally compute heavy after all. 50k entries isn't a whole lot but as people hosting Mastodon servers have found out, things start slowing down when 1000 people transfer th…

That might be true - but how else can it work? The data has to get onto the server somehow, and the days of unsigned or unencrypted data ended with Snowden.

The OP was going on about storing all the data on-device and uploading it, but regardless of where it’s stored, if a bunch of people have to move, the thundering herd problem, so to speak, will still exist.

Also, signature verification is not slow. I don’t know what AT uses or how good this source from 2020 is [0] nor what machine it ran on, but ed25519 verification takes about 50us for a 32 byte signature verification. That suggests this guys 50k posts will be validated in 2.5s. If we assume just a single server then that’s about 34k users per day. Or put another way, 30 servers to onboard one million people in a day. None of this seems outrageous to me.

[0] https://safenetforum.org/t/ed25519-vs-bls-performance/32613

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

#219

Post by aboodman »

vidarh wrote: post #165
luckystarr wrote: post #149

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

ActivityStreams just requires an object to have a unique URI. ActivityPub says it "should" be a https URI. However, since this URI is expected to be both unique and unchanging (if you put up the same content with a different id, it's a different object), you can choose to use it as the input to a hash function and put the posts in a content-addressable store. Mastodon will already check the local server first if you…

one important difference is:

> expected

Because the URI is only _expected_ to be immutable, not required, servers consuming these objects need to consider the case where the expectation is broken.

For example, imagine the serving host has a bug and returns the wrong content for a URI. At scale this is guaranteed to happen. Because it can happen, downstream servers need to consider this case and build infrastructure to periodically revalidate content. This then propagates into the entire system. For example, any caching layer also needs to be aware that the content isn't actually immutable.

With content hashes such a thing is just impossible. The data self-validates. If the hash matches, the data is valid, and it doesn't matter where you got it from. Data can be trivially propagated through the network.

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

#220

Post by einr »

anticristi wrote: post #83

Anyone else read "AT protocol" and thought of old modems?

Yes, this is a brutally poor choice of name. The AT command set is not only well known to virtually every computer person on the planet and has been for 40+ years, it is also not even obsolete but in constant use everywhere on the planet. Just... please change the name of whatever this is.
Post reply on HN