Building on ATProto

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.

As an extension of that I've been building a small language to build games (with a nice time traveling debugger and automatic replays) inspired by Elm. Go and Chess are both built on top of this and you could fork them and modify the rules. Want to code a new Chess variant? Go ahead! Want to code a whole new game you want to try? Go ahead!

What I'm very excited with ATProto is that because all games are broadcast on it and each shares a core system of turn-based replays (and review system with branching) software can be built on top to do AI analysis, or a replay view. The idea that my application can be extended without me adding an API is very exciting and very much in the direction I want to take the system (community is the core tenet).

Luke's feedback on the permissioned data proposal is pretty interesting. The current proposal has a kind of locational element to permissions, where a record's URI reflects the access control, and I can understand why that would be jarring. I'm talking with the team about whether we think that's something that could change, and what a change like that would cost. We're still in the collecting feedback phase so it's good to hear how it hits people.

Regarding his other concern, I would've loved to make atproto a localfirst protocol -- that's the field the atproto team came from -- but we had to pick & choose where to spend our complexity budget. I wouldn't say it's a nonstarter for the ecosystem; you can use something like iroh in conjuction with atproto to share identities -- dial people at their dids or domain names -- and then commit state to the atproto repo once it's ready to leave your local sync mesh. Maybe that sort of thing makes its way into future versions of the protocol. But, engineering often involves trades, and for the v1 that was one of the trades we had to make.

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 someone starts startup A on-top of the ATProto. They raise some money, get some users, some people love it, but ultimately they die. If the data was private to that service, that data dies with the startup. But if the data is all public future startup B can read that old data and do something with it. As a user that's brings me a ton of utility and comfort trying out new services.

If you're trying to built a local-first, mostly private service I just don't think the ATProto is the right tool for the job.

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.

I switched from codeberg to tangled, and the transition couldn't have been smoother. Being on the ATmosphere really helps with peace of mind.

The intention is good. I like the reviews idea. Since the author has hit the limitations of ATProto, could ActivityPub be an answer?

This author speaks to me!

> it should just be called “private data”

> the resulting design looks very hard to build on

> Private and public data are basically identical. ... The permission is world-read

Way back before Bluesky decided on their own what permissioned data would look like, when the Atmosphere Private Data WG still thought they had a say in the design, I gave a talk on a ReBAC/Zanzibar style system that aligns with what I think the author is looking for.

https://www.youtube.com/watch?v=oYKA85oZc8U&t=3730s

I suppose we could still build on and run a fork like mine if enough people wanted a more robust IAM system. There are some fundamental issues that I am not sure are resolvable without building them into the protocol core from the start. I have personally given up because of the leadership and am waiting/pondering the next protocol. Another design constraint I'd like to see is incentivizing apps to be federated and installable at the PDS as well as incentivizing small social over public square modalities.

https://github.com/verdverm/atproto

What's even the point of publishing anything online any more if you don't hope to become an influencer? The nature of the game has changed, and now does everything possible to discourage it.