Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ATProto for distributed system engineers

atproto.com

Post reply on HN
Print view View original

11–20 of 63 posts

Re: ATProto for distributed system engineers

#11

Post by zimpenfish »

m_eiman wrote: post #8
__loam wrote: post #6

Earlier quoted context omitted.

There's a lot fewer resources for AT than ActivityPub. Last time I checked which was a few months ago, the official documentation for AT was pretty sparse if you're interested in building to a spec. You'll find a lot more in the ActivityPub specs, plus a lot of open implementations and helpful guides.

> You'll find a lot more in the ActivityPub specs, plus a lot of open implementations and helpful guides. I've read that there's a problem with interacting with Mastodon if you only rely on the protocol specs, that they do things their own way and have different requirements than the official specs. Is this still a problem? If it is, are Mastodon moving to be more closely aligned with the spec, or to doing more of th…

From what I've seen, Mastodon sticks to the spec but a lot of clients and servers then stick to Mastodon's interpretation of the spec rather than the spec. e.g. for status IDs, the spec says "String (cast from an integer but not guaranteed to be a number)", Mastodon uses numerical IDs, some clients[1] see this as "Ah, IDs are numbers!" and break horribly when they're not numerically parseable (Akkoma, Pleroma, GotoSocial...)

(IIRC there was another thing where `created_at` is described as "The date when this status was created" but the type is given as "String (ISO 8601 Datetime)" which led some code to crash when Mastodon started outputting just dates instead of datetimes.)

[1] Including some from people who Really Should Know Better.

Re: ATProto for distributed system engineers

#12

Post by Kudos »

apitman wrote: post #3

Has anyone played around with ATProto yet? ActivityPub is pretty easy to get started with, especially if you just ignore JSON-LD and parse what you see. I'm curious how ATProto compares.

I only know of this blog implementation https://github.com/whtwnd/whitewind-blog

Re: ATProto for distributed system engineers

#14

Post by vidarh »

zimpenfish wrote: post #11
m_eiman wrote: post #8

Earlier quoted context omitted.

> You'll find a lot more in the ActivityPub specs, plus a lot of open implementations and helpful guides. I've read that there's a problem with interacting with Mastodon if you only rely on the protocol specs, that they do things their own way and have different requirements than the official specs. Is this still a problem? If it is, are Mastodon moving to be more closely aligned with the spec, or to doing more of th…

From what I've seen, Mastodon sticks to the spec but a lot of clients and servers then stick to Mastodon's interpretation of the spec rather than the spec. e.g. for status IDs, the spec says "String (cast from an integer but not guaranteed to be a number)", Mastodon uses numerical IDs, some clients[1] see this as "Ah, IDs are numbers!" and break horribly when they're not numerically parseable (Akkoma, Pleroma, GotoSo…

I like ActivityPub overall, but there are a lot of places where the spec is just too complex, and I suspect that contributed to a lot of the choices to implement whatever currently works with Mastodon instead of the spec.

I'm currently implementing parts of the spec, and there are parts (like fully handling context correctly) that feels like far more pain than it is worth vs. just handling occasional breakage.

It feels like a very ivory tower spec of the kind you wouldn't be likely to write if you built a complete reference implementation first.

But it's very on-brand as a W3C spec.

I'd love to see a revision that deprecates and simplifies a whole lot of things.

Re: ATProto for distributed system engineers

#15

Post by rapnie »

vidarh wrote: post #14
zimpenfish wrote: post #11

Earlier quoted context omitted.

From what I've seen, Mastodon sticks to the spec but a lot of clients and servers then stick to Mastodon's interpretation of the spec rather than the spec. e.g. for status IDs, the spec says "String (cast from an integer but not guaranteed to be a number)", Mastodon uses numerical IDs, some clients[1] see this as "Ah, IDs are numbers!" and break horribly when they're not numerically parseable (Akkoma, Pleroma, GotoSo…

I like ActivityPub overall, but there are a lot of places where the spec is just too complex, and I suspect that contributed to a lot of the choices to implement whatever currently works with Mastodon instead of the spec. I'm currently implementing parts of the spec, and there are parts (like fully handling context correctly) that feels like far more pain than it is worth vs. just handling occasional breakage. It fee…

> I'd love to see a revision that deprecates and simplifies a whole lot of things.

The hidden complexities in AP have led to several efforts. In the past there has been LitePub [0]. A recent project is Versia [1]. And who knows there may be a FeatherPub [2] one day. If anyone knows of other attempts I'd like to hear.

[0] https://litepub.social/

[1] https://versia.pub/

[2] https://docs.google.com/document/d/13LuB6Z-C_drCLCEuCtNApX98...

Re: ATProto for distributed system engineers

#17

Post by vidarh »

rapnie wrote: post #15
vidarh wrote: post #14

Earlier quoted context omitted.

I like ActivityPub overall, but there are a lot of places where the spec is just too complex, and I suspect that contributed to a lot of the choices to implement whatever currently works with Mastodon instead of the spec. I'm currently implementing parts of the spec, and there are parts (like fully handling context correctly) that feels like far more pain than it is worth vs. just handling occasional breakage. It fee…

> I'd love to see a revision that deprecates and simplifies a whole lot of things. The hidden complexities in AP have led to several efforts. In the past there has been LitePub [0]. A recent project is Versia [1]. And who knows there may be a FeatherPub [2] one day. If anyone knows of other attempts I'd like to hear. [0] https://litepub.social/ [1] https://versia.pub/ [2] https://docs.google.com/document/d/13LuB6Z-C_…

Thanks. I remember looking at Litepub. Not aware of the other two. The FeatherPub document feels like by far the most useful.

But I also think just going through the spec with a red marker would be a useful exercise and maybe I will one day.

In the sense that there are a whole lot of features nobody does anything useful with.

E.g. "@context" in theory provides a whole lot of ways to type the rest of the data. I'd be willing to bet that you'd break a whole lot of software if you served up a "@context" for an actor that mapped common field-names in use by Mastodon to a different namespace and mapped the Mastodon features to different names...

In theory it's great. In practice, I suspect we have XML namespaces and people stupidly hardcoding prefixes all over again...

Re: ATProto for distributed system engineers

#18

Post by nunobrito »

wmf wrote: post #4
omnicarinha wrote: post #2

One thing I still didn't quite grasp with BlueSky yet is if it's a decentralized platform or not... ATProto seems technically capable of supporting decentralized platforms.

It's pretty decentralized. You can run your own PDS, relay, and appview (some of these are more expensive than others). I'm not sure if you can configure the official clients to use an alternate server.

Decentralization on this social network context means to have users accessing data from other users even when other third-parties don't want you to.

That platform is (today) a centralized walled garden. As others detailed, it is difficult for anyone to add new servers and even more difficult to convince the official client to support them.

It is a complete contrast to NOSTR that has zero official servers and zero official clients to access the data. It has hundreds of relays from different people, along with several clients from different developers that compete for your preference.

Re: ATProto for distributed system engineers

#19

Post by Diti »

apitman wrote: post #3

Has anyone played around with ATProto yet? ActivityPub is pretty easy to get started with, especially if you just ignore JSON-LD and parse what you see. I'm curious how ATProto compares.

As an ontology enthusiast, it saddens me to see that ATProto went for their own data model ([link:Lexicon]) instead of using the standard JSON-LD (I wonder if they considered Turtle – which is streamable, unlike JSON).

I get why they did that (graph data is, uh, particular to work with, especially for newcomers who only know JSON), but ATProto not using JSON-LD is actually what made me unwilling to tinker with the protocol.

Not a direct answer to your question, sorry. Mostly a rant.

[link:Lexicon]: https://atproto.com/guides/faq#why-create-lexicon-instead-of...

Re: ATProto for distributed system engineers

#20

Post by str4d »

Diti wrote: post #19
apitman wrote: post #3

Has anyone played around with ATProto yet? ActivityPub is pretty easy to get started with, especially if you just ignore JSON-LD and parse what you see. I'm curious how ATProto compares.

As an ontology enthusiast, it saddens me to see that ATProto went for their own data model ([link:Lexicon]) instead of using the standard JSON-LD (I wonder if they considered Turtle – which is streamable, unlike JSON). I get why they did that (graph data is, uh, particular to work with, especially for newcomers who only know JSON), but ATProto not using JSON-LD is actually what made me unwilling to tinker with the pr…

There are a few more details about the reason they didn't use JSON-LD in Paul's blog post [0].

[0]: https://www.pfrazee.com/blog/why-not-rdf

Post reply on HN