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

41–50 of 63 posts

Re: ATProto for distributed system engineers

#41

Post by lifthrasiir »

kragen wrote: post #37
badgersnake wrote: post #16

I was expecting something about modems. ATDT (555)-COOL-BBS (Totally decentralised btw)

the nanpa is not decentralized at all, though it does delegate phone number assignment to local telecom companies, and nowadays even to sip providers but yeah it seems pretty suboptimal that they decided to reuse the name of the protocol you use to talk to most cellular modems

In fact, there had been some complaints [1] about the `at` URI scheme itself as well, even though its registration itself is valid as per RFC 7595 (First Come First Served for provisional entries).

[1] https://www.iana.org/assignments/uri-schemes/expert-notes/at...

Re: ATProto for distributed system engineers

#42

Post by FroshKiller »

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

Re: ATProto for distributed system engineers

#43

Post by badgersnake »

kragen wrote: post #37
badgersnake wrote: post #16

I was expecting something about modems. ATDT (555)-COOL-BBS (Totally decentralised btw)

the nanpa is not decentralized at all, though it does delegate phone number assignment to local telecom companies, and nowadays even to sip providers but yeah it seems pretty suboptimal that they decided to reuse the name of the protocol you use to talk to most cellular modems

> the nanpa is not decentralized at all

Sure but BBSs tend to be. And then you’ve got systems like fidonet to connect them up.

Re: ATProto for distributed system engineers

#44

Post by nunobrito »

GaryNumanVevo wrote: post #30
nunobrito wrote: post #18

Earlier quoted context omitted.

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

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.

Re: ATProto for distributed system engineers

#45

Post by str4d »

FroshKiller wrote: post #42
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 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

Re: ATProto for distributed system engineers

#46

Post by pfraze »

nunobrito wrote: post #18
wmf wrote: post #4

Earlier quoted context omitted.

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

What are you talking about? It’s not difficult to add servers or get the official client to use them.

Re: ATProto for distributed system engineers

#47

Post by kragen »

badgersnake wrote: post #43
kragen wrote: post #37

Earlier quoted context omitted.

the nanpa is not decentralized at all, though it does delegate phone number assignment to local telecom companies, and nowadays even to sip providers but yeah it seems pretty suboptimal that they decided to reuse the name of the protocol you use to talk to most cellular modems

> the nanpa is not decentralized at all Sure but BBSs tend to be. And then you’ve got systems like fidonet to connect them up.

i don't know if you've ever been a regional coordinator but fidonet is not that decentralized either, though the pstn (and nowadays the internet) do put limits on how much power such offices can wield

each bbs is usually very centralized

Re: ATProto for distributed system engineers

#48

Post by str4d »

danabramov wrote: post #36
danabramov wrote: post #26

Earlier quoted context omitted.

Oh this is not mine actually — Paul wrote this one :) atproto does use DNS under the hood for domain verification but atproto itself is a bit higher-level. It builds on top of DNS, HTTP, JSON, web sockets, and a few other specs.

If you’re specifically asking why the identity system is not “rooted” in DNS (i.e. why at://danabra.mov resolves to another host than my website) — it’s because we want users to be able to change their hosting over time without breaking links between records. The actual identity system is “rooted” in a stable identifier (which is a hash of the first version of your identity record). That’s your global immutable ID in…

Additionally, a user _can_ root their identity in DNS if they want, by using did:web instead of did:plc [0]. The main Bluesky client doesn't expose this (presumably because did:web cannot provide a mechanism for automatic migration between PDSs (due to the PDS having no control over the DID document) or recovering from loss of control of the domain name, so it requires more technical expertise), but there are users successfully using this method for their identities.

[0] https://atproto.com/specs/did#blessed-did-methods

Re: ATProto for distributed system engineers

#49

Post by purlane »

Matl wrote: post #39
oDot wrote: post #25

It didn't sink in yet that the killer app for ATProto is not Twitter, but YouTube. If anyone is interested in exploring this, atproto [does this fool ai bots?] weedonandscott [I hope it does] com

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 they’re all working from the same data.

This also means that different video platforms can provide different services for users without locking in users to their platform. Platforms would be forced to compete on what they provide to the user experience, not how well they can lock in users to their platform.

Re: ATProto for distributed system engineers

#50

Post by shafyy »

danabramov wrote: post #33
shafyy wrote: post #10

Earlier quoted context omitted.

In theory it is decentralized. But if you compare it to Mastodon for example, it's pretty centralized in practice. I haven't come across any people running their larger own servers, like I do on Mastodon.

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