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

ATProto for Distributed Systems Engineers

atproto.com

Post reply on HN
Print view View original

21–30 of 31 posts

Re: ATProto for Distributed Systems Engineers

#21

Post by Longwelwind »

giancarlostoro wrote: post #19
jmusall wrote: post #11

Earlier quoted context omitted.

The article did not make me understand that at all. > Since we're making a new app, we're going to want two things: an app server (which hosts our API & frontend) and a view server (which collects data from the network for us). Yes, the user data is decoupled from the apps, but aren't both stored on some kind of instances ? Also: > Why are we listening to the event stream if we're the one making the write? Because we…

Lol reminds me of "ITS SERVERLESS!" Which always cracks me up, as someone who does find serverless useful for very strategic scenarios, naming things as though they don't require a computer somewhere to function has been one of the weirdest trends in tech.

The name "serverless" doesn't mean that there are no servers. It means that, as a developer, you don't need to manage the server. It's abstracted out for you.

Re: ATProto for Distributed Systems Engineers

#22

Post by giancarlostoro »

Longwelwind wrote: post #21
giancarlostoro wrote: post #19

Earlier quoted context omitted.

Lol reminds me of "ITS SERVERLESS!" Which always cracks me up, as someone who does find serverless useful for very strategic scenarios, naming things as though they don't require a computer somewhere to function has been one of the weirdest trends in tech.

The name "serverless" doesn't mean that there are no servers. It means that, as a developer, you don't need to manage the server. It's abstracted out for you.

I know what it means, I pitched serverless as a new tool to a former employer back nearly a decade ago, I had to thoroughly research it because the manager would of said no if I had no idea how it worked, funnily enough, he said yes before I could finish my entire pitch.

The name still sounds silly.

Re: ATProto for Distributed Systems Engineers

#23

Post by evbogue »

jauntywundrkind wrote: post #14
evbogue wrote: post #7

Earlier quoted context omitted.

Yah it clearly has always done this, but why doesn't it support multi-PDS replication? But you're right that the screenshot proto and the copy and paste proto are quite successful as a distributed system these days.

There's nothing stopping multi-PDS replication right now. It would work fine. No one would know that content is available elsewhere, is kind of the main chicken-and-egg problem. Hubble is starting to come online, which is a network cache. With excellent storage and runtime characteristics, cheap to run. I'm not sure if this is in the same https://microcosm.blue banner-head, but the same developer, as another incredib…

Having the content available everywhere seems like the definition of a distributed system to me. Hashing content is not a discovery issue, one simply iterates over a list of hosts and asks if they have the msgs by their hash.

Re: ATProto for Distributed Systems Engineers

#24

Post by pfraze »

evbogue wrote: post #23
jauntywundrkind wrote: post #14

Earlier quoted context omitted.

There's nothing stopping multi-PDS replication right now. It would work fine. No one would know that content is available elsewhere, is kind of the main chicken-and-egg problem. Hubble is starting to come online, which is a network cache. With excellent storage and runtime characteristics, cheap to run. I'm not sure if this is in the same https://microcosm.blue banner-head, but the same developer, as another incredib…

Having the content available everywhere seems like the definition of a distributed system to me. Hashing content is not a discovery issue, one simply iterates over a list of hosts and asks if they have the msgs by their hash.

What would be the upsides and downsides of that? It’s unclear what you’re asserting. Do you just want IPFS?

Re: ATProto for Distributed Systems Engineers

#25

Post by mort96 »

giancarlostoro wrote: post #19
jmusall wrote: post #11

Earlier quoted context omitted.

The article did not make me understand that at all. > Since we're making a new app, we're going to want two things: an app server (which hosts our API & frontend) and a view server (which collects data from the network for us). Yes, the user data is decoupled from the apps, but aren't both stored on some kind of instances ? Also: > Why are we listening to the event stream if we're the one making the write? Because we…

Lol reminds me of "ITS SERVERLESS!" Which always cracks me up, as someone who does find serverless useful for very strategic scenarios, naming things as though they don't require a computer somewhere to function has been one of the weirdest trends in tech.

I don't see the connection. The article is full of talk of servers: app servers, view servers, database servers, event log servers, ...

Re: ATProto for Distributed Systems Engineers

#26

Post by mort96 »

echelon wrote: post #8
LelouBil wrote: post #2

I feel like it's the best ATProto architecture explanation on the web. I hope it will make people who argue that "there are no instances in ATProto" is wrong, understand that it is actually true and not just a naming debate.

Is ATProto federated, P2P, or a protocol flexible enough to build all kinds of things? Is it opinionated about which type of system to build? Skimming this page, it looks like ATProto is a schema for the ontology, and despite saying "P2P", it looks built around federation and concerned about scaling infrastructure (rather than scaling message broadcast). I'm interested in a p2p social network with federated supernode…

Mastodon works like email. Users have their data hosted on instances and most big instances can communicate with most other big instances, and all instances blacklist a bunch of other instances for spam or political reasons. Just like e-mail.

Re: ATProto for Distributed Systems Engineers

#27

Post by culi »

echelon wrote: post #8
LelouBil wrote: post #2

I feel like it's the best ATProto architecture explanation on the web. I hope it will make people who argue that "there are no instances in ATProto" is wrong, understand that it is actually true and not just a naming debate.

Is ATProto federated, P2P, or a protocol flexible enough to build all kinds of things? Is it opinionated about which type of system to build? Skimming this page, it looks like ATProto is a schema for the ontology, and despite saying "P2P", it looks built around federation and concerned about scaling infrastructure (rather than scaling message broadcast). I'm interested in a p2p social network with federated supernode…

ATProto is definitely not P2P and probably not federated. Every user has their own personal storage and gives apps like Bluesky permission to write to them.

They solve different problems and, in theory, you can use ATProto and ActivityPub (Mastodon/Threads/Peertube/etc) together

Re: ATProto for Distributed Systems Engineers

#28

Post by culi »

blackqueeriroh wrote: post #10
echelon wrote: post #8

Earlier quoted context omitted.

Is ATProto federated, P2P, or a protocol flexible enough to build all kinds of things? Is it opinionated about which type of system to build? Skimming this page, it looks like ATProto is a schema for the ontology, and despite saying "P2P", it looks built around federation and concerned about scaling infrastructure (rather than scaling message broadcast). I'm interested in a p2p social network with federated supernode…

Any PDS can talk to another PDS, yes.

They do not directly talk/query each other. But Relays and AppViews allow PDS's to be aggregated to create apps like BlueSky.

I don't think anyone would describe ATProto as p2p

Re: ATProto for Distributed Systems Engineers

#29

Post by nikhilsimha »

Shameless plug, we built Chronon to solve a very similar problem. Chronon is now open source (apache 2) and used at Netflix, OpenAI, Airbnb, Stripe etc.

It is used to serve features/context to ML/AI models and rule engines, along with app views.

We are more scale and perf oriented as project given the use-cases and less decentralization oriented.

We also ship with a dataframe / prql like declarative api.

[1] https://chronon.ai

Re: ATProto for Distributed Systems Engineers

#30

Post by evbogue »

pfraze wrote: post #24
evbogue wrote: post #23

Earlier quoted context omitted.

Having the content available everywhere seems like the definition of a distributed system to me. Hashing content is not a discovery issue, one simply iterates over a list of hosts and asks if they have the msgs by their hash.

What would be the upsides and downsides of that? It’s unclear what you’re asserting. Do you just want IPFS?

IPFS already exists. What I want is distributed Bluesky, since it's a product success and I do like most of the proto and the team. Do you want to fix this? I just spoke with Claude and I don't think it'd be too difficult these days for us to fix this in the core product.
Post reply on HN