Hacker News Reader

Comment by apitman | Hacker News Reader

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.

View on HN

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

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

I'm sorry but JSON-LD is a massive pain to work with in statically typed languages. Certainly is in Go at least. The flexibility is the problem, ie you never know if something is going to be an object or an IRI (did we really need a 3rd name for URIs?) to an object. I think you could get most of the benefit while still requiring specific types.

You shouldn’t be having this problem if you use a library which offers normalization (like github.com:piprate/json-gold) so that you get objects when there’s an IRI context, and a simple string when there’s a regular IRI.

I'm not aware of any such libary for Go. Besides, I prefer protocols that are simple enough to implement myself. That's not feasible in every case, but it certainly is for the social media use case.

We've just released a new short guide on creating a minimal app on atproto, together with a GitHub example project:

- https://atproto.com/guides/applications

- https://github.com/bluesky-social/statusphere-example-app

I built a custom feed server for Bluesky that drinks from the firehose. Getting everything working was very fiddly. For a hobby, the friction of it outweighed the entertainment value for me.

Working with the firehose probably isn't feasible for a lot of people who'd like to tinker. There doesn't seem to be any way of subscribing to only certain types of events.

For a lower-friction firehose experience, you can use Jetstream [0] (by one of the Bluesky devs) which supports subscribing to specific Collection NSIDs and user repositories, and converts records to JSON for you.

There's a public instance URL in the README (with bandwidth limits), or you can self-host.

[0] https://github.com/ericvolp12/jetstream

The firehose itself isn't really the fiddly part since it's just a WebSocket connection. Setting up the feed server, publishing the DID for its web host, then publishing the feed generator to the network were all kind of a low-grade hassle that killed a lot of my enthusiasm. Like none of it was especially complicated if you're doing it for a professional project or whatever, but I was just trying to goof around while watching episodes of Highlander: The Series, and it was taking me away from Duncan.

I'll check out this Jetstream project for sure, though.

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

For non-Bluesky apps built in ATProto, in addition to White Wind (blogging), there is also Smoke Signal (events, only Lexicons are open source currently AFAICT) [0], and Frontpage (link aggregation) [1].

[0]: https://github.com/SmokeSignal-Events/lexicon

[1]: https://github.com/likeandscribe/unravel/tree/main/packages/...

Also, our new little example app:

- https://atproto.com/guides/applications (guide)

- https://github.com/bluesky-social/statusphere-example-app (GitHub)

yes we built a 10k user social network for artists and musicians on it and it’s excellent. very sophisticated and very extensible.

Might sharing a link?

Judging by this user’s comment history, the website seems to be solarplex.xyz (be advised, it takes between 30 seconds and 1 minute to fully load the website’s 75 MB).

OT but out of 572 requests, half of them are OPTIONS. CORS is an abomination.

yes :) we also stopped maintaining the old code starting may/june after running it for about 9 months. a new version of the front end is in the works!

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 their own thing?

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.

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.

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

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

Ah, FeatherPub is in a google doc. That explains why I was having trouble googling it last night.

Also, there's a conversation happening about Versia today: https://social.coop/@smallcircles/113105954469059880

Yes, there's a related google doc delving into the data model:

https://docs.google.com/document/d/13mtl9gFmcuL-0MS-Boaeh3i6...

OP is a link to the atproto site because it got a major new revision within the last week

Reply on news.ycombinator.com