underrated part of atproto is most of the time you don’t ha…

Samuel

@samuel.fm

underrated part of atproto is most of the time you don’t have to directly talk to other people’s (possibly badly made) servers, it’s all mediated via records

Emelia@thisismissem.social· 4 Jul

Oh dear lord, I knew it was bad, but didn't know it was this bad: hackers.pub/@fedify/2026... (I've mostly just contributed to activitypub projects that already existed, so didn't usually need to experience these specific pains)

Why implementing ActivityPub is hard, and why it doesn't have to be

Implementing the ActivityPub protocol from scratch introduces massive technical hurdles, including fragmented signature standards, unpredictable JSON-LD document variations, complex distributed system...

hackers.pub

6 19 133

Samuel 4 Jul

double-knocking in particular is diabolical

1 1 20

Thoth 4 Jul

I mean I'm sure that atproto itself will develop more and more similarly ugly warts (we've already got a few...), interoperability pitfalls, and questionable behavior over time, so I'm gonna get toooooo high and mighty.

2 5

Thoth 4 Jul

But also, ActivityPub is kind of extra bad about this for a whole bunch of reasons to do with the way the spec was written and the way that ecosystem evolved.

ntm 4 Jul

It's possible we can define equivalence classes and lenses to smooth over some of these warts with panproto.dev or something like it

panproto | schematic version control

One engine for schematic version control within and across any schema language. Built on generalized algebraic theories for provably correct migrations.

panproto.dev

1 1

Thoth 4 Jul

I mean that doesn't help with weird protocol quirks or the classic well-this-isn't-standard-behavior-but-it-was-accepted-pre-standard-and-a-few-large-implementations-still-do-it-so-everyone-needs-to-support-it-forever.

Emelia 4 Jul

You can still umm, have badly written records or missing lexicons.. and sometimes you deal with someone's non-spec implementation of oauth

1 11

Samuel 4 Jul

oh for sure, you still have to work with other parties at the end of the day, they’ll inevitably find ways to let you down. at least the surface area is much reduced

Indeed!

Also we don't use RDF and don't have to worry about RDF canonicalization. (I'm not going to do my RDF rant again. Just... kind of take it as read that it goes here.)

1 2

Emelia 4 Jul

There's dealing with different lexicons or technically invalid record data, and then there's RDF for sure. As i've noted when talking about Solid: RDF was one of the biggest stumbling points in people trying to adopt it.

bolson 4 Jul

Yup, Relay (the bit that gathers from all the PDS and makes the firehose) does some amount of validating and normalizing possibly rough PDS implementations

metru 4 Jul

Currently just hacking away with a lib to talk to my pds. Maybe in a month I'll try to make my own server. Would be such a cool idea for a codecrafters.io project.

CodeCrafters | The Hardest Programming Challenges on the Internet

Build your own Redis, Git, SQLite, and more from scratch. Advanced challenges designed for experienced engineers, used by developers at Google, OpenAI, and Vercel.

codecrafters.io