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

51–60 of 63 posts

Re: ATProto for distributed system engineers

#51

Post by apitman »

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…

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.

Re: ATProto for distributed system engineers

#52

Post by apitman »

Diti wrote: post #38
danabramov wrote: post #35

Earlier quoted context omitted.

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.

Re: ATProto for distributed system engineers

#53

Post by apitman »

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_…

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

Re: ATProto for distributed system engineers

#54

Post by oDot »

purlane wrote: post #49
Matl wrote: post #39

Earlier quoted context omitted.

ActivityPub does have https://joinpeertube.org for what it's worth. What would ATProto bring in specifically? Is it the ease of migration?

The biggest upside compared to PeerTube is probably discoverability. In ActivityPub, the network architecture means the video ecosystem is fractured and there’s no one cohesive place to find all PeerTube videos. In atproto, the network is continually indexed by relays, which means that it doesn’t make a difference what app you use to watch videos - you’ll find the exact same ones regardless of the platform, since the…

Exactly right.

Watch apps will compete on consumer-facing features like the recommendation algorithm -- maybe they'll offer several, or just one that differentiates them.

Hosting providers will compete on producer-facing features, like advertising, content policies, analytics, etc.

If a user is displeased with either, they can take all of their content/activity history and leave.

Re: ATProto for distributed system engineers

#55

Post by GaryNumanVevo »

nunobrito wrote: post #44
GaryNumanVevo wrote: post #30

Earlier quoted context omitted.

There are already alternative clients that support custom AppViews and relays

Described as "3rd party client" and which aims as goal to connect with NOSTR: https://docs.bsky.app/blog/feature-skyfeed Twitter also had 3rd party clients until one day they turned off the switch. Around NOSTR there are no labels as "3rd party clients" because they can't lock down your data with the push of a switch nor block your use of the platform.

What's not to understand here? The PDS isn't a relay, it's a repository. The data layer is decoupled from the message passing layer, that's it.

Re: ATProto for distributed system engineers

#56

Post by danabramov »

shafyy wrote: post #50
danabramov wrote: post #33

Earlier quoted context omitted.

Note the shape of decentralization is very different from Mastodon — there's no concept of "running a Bluesky instance". What you can run is a personal server to host your data (which would work for any atproto apps, not just Bluesky). The Bluesky web app (which is ran by Bluesky) would aggregate data from your server (and all other servers on the network). Unlike Mastodon, you don't have people running copies of the…

Sure, but I still haven't seen people really doing that.

Which part are you referring to by “that”? There’s definitely people self-hosting their data (not a lot cause the process is pretty technical and manual atm). Note that you can always move hosts (without asking permission from the previous host) so you can start using the Bluesky hosting and then switch it.

Re: ATProto for distributed system engineers

#57

Post by Diti »

apitman wrote: post #51
Diti wrote: post #19

Earlier quoted context omitted.

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…

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.

Re: ATProto for distributed system engineers

#58

Post by rapnie »

apitman wrote: post #53
rapnie wrote: post #15

Earlier quoted context omitted.

> 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_…

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

Re: ATProto for distributed system engineers

#59

Post by FroshKiller »

str4d wrote: post #45
FroshKiller wrote: post #42

Earlier quoted context omitted.

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.

Re: ATProto for distributed system engineers

#60

Post by apitman »

Diti wrote: post #57
apitman wrote: post #51

Earlier quoted context omitted.

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.
Post reply on HN