No. Data is stored on your PDS and no one else can shut it down, there is no central server. The only difference from public atproto is when you ask someone else PDS for records in a space you need a token signed by the space authority to show that you have permission to read them.

So your PDS is a central server?

Who would I ask for my private space records but myself?

Think less "private" and more "protected." Like Patreon subscriber perks, paywalled content, or just someone who only wants certain people to see what they post.

Who would you ask besides the author's PDS though? Would every relay have a cached copy of all private data, but only give it out after checking auth? That's not a very safe design - what if my relay doesn't check?

spaces do not use relays. The sync protocol is pull from PDS. https://dholms.leaflet.pub/3mqtqvjidqs2p

So it's a central server and doesn't benefit from being ATP as it can be anything you want.

“Protected” is the same thing at the technical level. Both would 401 or 403 to the unauthorized user.

I think they are asking how it actually works not for product marketing

ATProto is basically old web where you host your own content and advertise an RSS feed except there are aggregators that make everyone’s feed into one big firehouse that you can filter down to content you want to follow, and then view the content with whatever client you want (AppViews which are also servers but they can be pointed to a feed made up of others servers, like a Web Ring!)

I could hate on them for reinventing the wheel but the cryptographic stuff they do with signed merkle trees is pretty clutch, it’s a tricky problem to untangle public key identities from domains so you can migrate your content without losing your identity. There’s still not a good flow for that but at least there’s the groundwork done.

And yet, they don't advertise content hashes so the data cannot be distributed by the software.

Yes like all of this would benefit from their team studying the implementation of Tahoe-LAFS.

That's directly addressing vendor lock in

A server protocol. Like HTTP.

Sure they are linked by this general category of app layer service protocols, but they are different. ATProto afaik is a bit like activitypub, in which you define a protocol on top of the state representation in a way you can transfer it reliably across instantes that implement them.

It's like http in which you can achieve the same using http, but http isn't prescriptive about any such behaviours, which these protocols address

Does it operate on top of HTTP? I'm asking honestly, don't know the ATProto, if it is the yes, kinda, although REST isn't prescriptive about permissions, which the protocol also seems to be all about.

REST is a set of conventions for HTTP

Sorry, I meant atproto. Does it operate on top of http? At this point I could have already searched by myself but I prefer to keep it a conversation