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

ATProto spaces: A new extension to ATProto that enables non-public data

atproto.com

Post reply on HN
Print view View original

31–38 of 38 posts

Re: ATProto spaces: A new extension to ATProto that enables non-public data

#31

Post by notnullorvoid »

It seems like at every turn the word private is avoided and replaced with "non-public".

I understand that the system probably is sound, the data just isn't encrypted, which I wouldn't necessarily expect. Maybe it's completely clear for users familiar with AtProto, but for others it needs to be clearer on some things:

- Where exactly is the data is stored

- Who is the "space authority" and why should they be trusted

- Strategies where you can manually encrypt/decrypt the data put in spaces

And avoid sketchy sounding terms like "non-public".

Re: ATProto spaces: A new extension to ATProto that enables non-public data

#34

Post by curious_cat_163 »

notnullorvoid wrote: post #31

It seems like at every turn the word private is avoided and replaced with "non-public". I understand that the system probably is sound, the data just isn't encrypted, which I wouldn't necessarily expect. Maybe it's completely clear for users familiar with AtProto, but for others it needs to be clearer on some things: - Where exactly is the data is stored - Who is the "space authority" and why should they be trusted -…

I am not developing with the ATproto, but keep an eye on the specs. There is a lot brewing in that ecosystem so I understand your skepticism.

I think that avoiding the word “private” is absolutely the right move here, because they are not building for the individual privacy. That’s not what the spec is intending to unlock. Their goal is to enable the next set of apps, that need to enable sharing of content with a specific and controlled group of users.

The data is stored in a PDS. You can use the one that Bluesky PBC or any other service provider provides, or you can self-host.

Space Authority is a DID, per the link above. So, in ATProto land, that’s just an account. The authority DID controls the accesss to the the space for other DIDs.

I can’t answer your question about encryption. Hard to answer it without a specific use case.

Re: ATProto spaces: A new extension to ATProto that enables non-public data

#35

Post by irickt »

jodosha wrote: post #20

> It’s important to remember that spaces give you access control not confidentiality. The data in a space is readable by any user or application with access to that space, it’s not encrypted.

As the next sentence says "Spaces are a very flexible primitive, and the range of uses is deliberately broad." Access control by groups fits a wide range of applications. Encryption with multiple access is a specialized need that might be built on the primitive.

Re: ATProto spaces: A new extension to ATProto that enables non-public data

#36

Post by chokolad »

inigyou wrote: post #24
oddevan wrote: post #19

Earlier quoted context omitted.

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

Re: ATProto spaces: A new extension to ATProto that enables non-public data

#37

Post by fereira »

dawnerd wrote: post #32
arikrahman wrote: post #9

Let's go, tangled.sh is about to have private repos

You sure about that? From my reading nothing about this is private.

As someone else pointed out, the word "non-public" is used to distinguish from the existing data, where everything is public. I'm not the guy who wrote it, but if I had to guess why that language was chosen, it would be because there's a lot of emphasis on spaces being scalable up to millions of users (think paywalled Patreon content, or something similar), and private implies a much tighter restriction. Set up a space with just you and your collaborators, put all your tangled data for a repo in it, do a little extra work on the knot implementation to actively authorize SSH connections (as that wasn't a concern when everything was public) and now that's a private repo.

Re: ATProto spaces: A new extension to ATProto that enables non-public data

#38

Post by inigyou »

chokolad wrote: post #36
inigyou wrote: post #24

Earlier quoted context omitted.

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