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

Building on ATProto

lukekanies.com

Post reply on HN
Print view View original

11–20 of 99 posts

Re: Building on ATProto

#11

Post by verdverm »

fidotron wrote: post #8
verdverm wrote: post #6

Earlier quoted context omitted.

> The ATProto was designed around all data being public. I might turn this around to say that ATProto was the square peg trying to fit into the round hole (the vast majority of people want privacy)

The main need is strong authentication, certainly for enabling P2P microblogging type apps. The privacy stuff is covered by Signal etc. anyway, and you could layer that on top if you wanted to, but in a P2P setup privacy is always going to be a bit disappointing as so much metadata is inevitably exposed unless you do crazy stuff like flood fill the network with every message without regard to routing.

The definition of privacy is a spectrum, with what you describe at the most information secops end. Most people are not so worried about metadata leakage (they don't even know what it is, similar to atproto for most bluesky users).

What most want is to not be reposted and ratio'd by terminally online people like Blue MAGA did on Bluesky. They also just want to post to their followers or friends, not the world.

Re: Building on ATProto

#12

Post by verdverm »

MarceColl wrote: post #3

I've been building a board game community on ATProto. The idea revolves in trying to build the feeling of local clubs but online, instead of "PLAY NOW" being on the landing page (although you can play now if you want) it's organized around clubs. I also wanted to move away from one game oriented community. I play Go and Chess and I would love clubs to be for mixed games. You can create leagues, or tournaments, etc. A…

How do you prevent a player from manipulating game state outside of the app view?

There is a subgroup in the Atmo working on games, have you found them yet?

Re: Building on ATProto

#13

Post by verdverm »

embedding-shape wrote: post #7
ekosz wrote: post #5

Reading articles like this one, I do think people are trying to put a square peg (their applications) through a round hole (ATProto). The ATProto was designed around all data being public. You write public data to a user's PDS and then any application can read that public data and do something with it. If all data was private (encrypted?) by default then that would defeat half of all of ATProto's goals. Imagine someo…

> If all data was private (encrypted?) by default then that would defeat half of all of ATProto's goals. Yeah, this is the reason why I don't understand why they succumbed to the idea ATProto must handle private and has started on work trying to figure it out ( https://atproto.wiki/en/working-groups/private-data ). Instead, focus on just really great public data archiving and displaying, at scale.

> I don't understand why they succumbed to the idea ATProto must handle private

The answer is very simple, the people demand it.

Technically, or if you squint the right way, it is a new protocol (atp://) that shares some parts with the public side. Notably the relay is out (for now?) and the data lives in a different sqlite table (iirc/aiui).

Re: Building on ATProto

#14

Post by jshen »

ekosz wrote: post #5

Reading articles like this one, I do think people are trying to put a square peg (their applications) through a round hole (ATProto). The ATProto was designed around all data being public. You write public data to a user's PDS and then any application can read that public data and do something with it. If all data was private (encrypted?) by default then that would defeat half of all of ATProto's goals. Imagine someo…

If the primary user concern is "all data is public", then the utility of ATProto is extremely narrow and will likely lose to something with a different philosophy.

Re: Building on ATProto

#15

Post by fidotron »

verdverm wrote: post #11
fidotron wrote: post #8

Earlier quoted context omitted.

The main need is strong authentication, certainly for enabling P2P microblogging type apps. The privacy stuff is covered by Signal etc. anyway, and you could layer that on top if you wanted to, but in a P2P setup privacy is always going to be a bit disappointing as so much metadata is inevitably exposed unless you do crazy stuff like flood fill the network with every message without regard to routing.

The definition of privacy is a spectrum, with what you describe at the most information secops end. Most people are not so worried about metadata leakage (they don't even know what it is, similar to atproto for most bluesky users). What most want is to not be reposted and ratio'd by terminally online people like Blue MAGA did on Bluesky. They also just want to post to their followers or friends, not the world.

So in your concept if you are A and have two folowers B and C that don't know each other but both comment on your post what should happen? Should you see both but they not see each other?

This is the tip of the iceberg of boring questions that fall out, all of which have annoying user experience implications which are intimately tied to the underlying infrastructure and cryptosystems, effectively setting them in stone. There are reasons these systems fall into the camps of either federated with strong ID or really very centralized.

Re: Building on ATProto

#16

Post by verdverm »

fidotron wrote: post #15
verdverm wrote: post #11

Earlier quoted context omitted.

The definition of privacy is a spectrum, with what you describe at the most information secops end. Most people are not so worried about metadata leakage (they don't even know what it is, similar to atproto for most bluesky users). What most want is to not be reposted and ratio'd by terminally online people like Blue MAGA did on Bluesky. They also just want to post to their followers or friends, not the world.

So in your concept if you are A and have two folowers B and C that don't know each other but both comment on your post what should happen? Should you see both but they not see each other? This is the tip of the iceberg of boring questions that fall out, all of which have annoying user experience implications which are intimately tied to the underlying infrastructure and cryptosystems, effectively setting them in ston…

> what should happen?

A core principle of ATProto is that the cost of switching is low, thereby facilitating real competition on social media. So the answer is two parts

1. App views decide permission parameters for their modality and frame the user experience

2. Users use these permission parameters to dial in their personal or community experience

I believe there is more middle ground than you leave space for. See systems like ReBAC/Zanzibar, Anonymous Credentials, and UCANN. Google Workspace is a good model that many many people understand and are happy with (IAM wise).

With a design like this, you can build an enforceable world-read, mutual-following-write version of Bluesky, something users ask for every time Bluesky announces any new feature.

Re: Building on ATProto

#17

Post by psionides »

jshen wrote: post #14
ekosz wrote: post #5

Reading articles like this one, I do think people are trying to put a square peg (their applications) through a round hole (ATProto). The ATProto was designed around all data being public. You write public data to a user's PDS and then any application can read that public data and do something with it. If all data was private (encrypted?) by default then that would defeat half of all of ATProto's goals. Imagine someo…

If the primary user concern is "all data is public", then the utility of ATProto is extremely narrow and will likely lose to something with a different philosophy.

That is about to change very, very soon though: https://dholms.leaflet.pub

Re: Building on ATProto

#18

Post by Striving7340 »

ATProto and its advocates increasingly sound like all the crypto-based decentralized platforms that failed. The difference is that crypto people actually had reasons to run nodes, they got paid to, while ATProto expects enthusiasts to do so for the love of the game or act like bluesky and have 99% of the "decentralized" platform on a centralized node.

It never catches on with application developers because it requires you to already worship the protocol and build around it.

Re: Building on ATProto

#19

Post by andunie »

Striving7340 wrote: post #18

ATProto and its advocates increasingly sound like all the crypto-based decentralized platforms that failed. The difference is that crypto people actually had reasons to run nodes, they got paid to, while ATProto expects enthusiasts to do so for the love of the game or act like bluesky and have 99% of the "decentralized" platform on a centralized node. It never catches on with application developers because it require…

I don't think anyone ever got paid to "run nodes".

Re: Building on ATProto

#20

Post by LoganDark »

andunie wrote: post #19
Striving7340 wrote: post #18

ATProto and its advocates increasingly sound like all the crypto-based decentralized platforms that failed. The difference is that crypto people actually had reasons to run nodes, they got paid to, while ATProto expects enthusiasts to do so for the love of the game or act like bluesky and have 99% of the "decentralized" platform on a centralized node. It never catches on with application developers because it require…

I don't think anyone ever got paid to "run nodes".

I think what they're talking about is like how bitcoin miners get paid in bitcoin for mining
Post reply on HN