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

421–430 of 493 posts

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

#421

Post by [deleted] »

throwaway5371 wrote: post #332
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 advice is dont stress, whatever you do, some people will not like it for some reason people think what we have now is good, and they say "dont reinvent the wheel" but there is no wheel, what we have is just garbage, 50 years and later we still cant beat the "unix pipe" we have to keep trying to make a wheel

[deleted]

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

#422

Post by JohnFen »

topaz0 wrote: post #333
pera wrote: post #211

Earlier quoted context omitted.

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.

"crypto" was used to mean cryptography long before it was used to mean currency, and in some circles still primarily means cryptography.

> in some circles still primarily means cryptography.

It still does in my circle. The overloading of "crypto", though, has become such a source of confusion and misunderstanding that I have stopped using it and just use the full word, be it cryptography or cryptocurrency, instead.

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

#423

Post by vidarh »

mkr-hn wrote: post #417
vidarh wrote: post #186

Earlier quoted context omitted.

Mastodon does not currently support importing posts from your old account. Just followers/following. It's a nuisance, and there's nothing preventing it per se, since the posts are signed, but that part could be better.

Calckey recently gained the ability to migrate posts. Even from Mastodon. Maybe that'll motivate Mastodon and the forks to prioritize it.

That's great. I'll have to take a look.

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

#424

Post by JohnFen »

ciex wrote: post #367
LeoPanthera wrote: post #18

It's not that bad. ATZ and ATDT are the main two you have to remember. Wait, is that not what we're talking about? So, it has a confusing name too?

There's only so many few letter combinations and we should reuse them.

Reusing obsolete ones make sense, but the Hayes AT protocol is still in very active use. Sadly.

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

#426

Post by cozzyd »

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.

Speaking of which, does anybody know a good freestanding C library that doesn't use dynamic allocation for the Hayes AT protocol?

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

#427

Post by moritz »

DannyBee wrote: post #354
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…

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?

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

#428

Post by stavros »

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.

ATDT12398192831

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

#429

Post by toomim »

Arathorn wrote: post #285
panick21_ wrote: post #201

Earlier quoted context omitted.

I have not looked much at AT, but it seems it solves many of the same problems as Matrix. Instead of redoing all the Crypto and everything, why not build on martrix. There were other Twitter like things on Matrix before. As far as I'm aware its developed on Matrix and had some connection with it, so this isn't a case of not knowing about it so there is likely some engineering reasons why this was not done. Would be i…

AT proto has some significant similarities to Matrix: * Both are work by self-authenticating git-style replication of Merkle trees/DAGs * Both define strict data schemas for extensible sets of events (Matrix uses JSON schema - https://github.com/matrix-org/matrix-spec/tree/main/data/eve... and OpenAPI; AT uses Lexicons) * Both use HTTPS for client-server and server-server traffic by default. * Both are focused on dec…

Ah, this is a wonderful analysis! Thank you, I've favorited it. :)

I'd love to get the decentralized protocols to work together. I work on braid.org, where we want to find standards for decentralized state sync, and would love to help facilitate a group dialogue. Hopefully I can connect with you more in the future.

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

#430

Post by Arathorn »

toomim wrote: post #429
Arathorn wrote: post #285

Earlier quoted context omitted.

AT proto has some significant similarities to Matrix: * Both are work by self-authenticating git-style replication of Merkle trees/DAGs * Both define strict data schemas for extensible sets of events (Matrix uses JSON schema - https://github.com/matrix-org/matrix-spec/tree/main/data/eve... and OpenAPI; AT uses Lexicons) * Both use HTTPS for client-server and server-server traffic by default. * Both are focused on dec…

Ah, this is a wonderful analysis! Thank you, I've favorited it. :) I'd love to get the decentralized protocols to work together. I work on braid.org, where we want to find standards for decentralized state sync, and would love to help facilitate a group dialogue. Hopefully I can connect with you more in the future.

have been tracking braid since the outset - providing state sync at the HTTP layer itself is a really interesting idea. would be great to figure out how to interop the various DAG based sync systems, or at least map between them. very happy to chat about this!
Post reply on HN