Post

Something I haven't talked much about: what exactly is The Pentaract going to do? This is probs important info for any #GameDev that's wondering how they can make use of my work. 🧵

First, it's a dashboard for developers to manage their games on ATProto. Create, update, and delete all your game info in one place.

Next: a claim/migration system. We'll create game records in the @gamesgamesgamesgames.games PDS, then developers can claim their games and migrate them to their own PDS for total ownership.

0 reposts3 likes

So cool! Do you have a writeup anywhere about how this system is intended to work? Where does preloaded data live before it's claimed + migrated to the owner's repo? On-protocol in the app's PDS, or only available via an appview RPC call? Do refs to this data survive the migration? How?

When I've tried to whiteboard similar designs in the past, I've imagined creating distinct DIDs for each owner of unclaimed on-protocol records, then updating the DID document to transfer ownership later But I always got stuck on the issue of owners whose claim arrived with their own existing DID

Also, are claims ever revocable? Or, assuming you're careful enough about properly resolving claims in the first place (no backsies), then is the plan to allow social pressure to deal with claimants whose data goes stale?

For my system, I have a multi-stage contribution system set up. Contributors can suggest changes to a record. Those changes can be reviewed by a moderator, OR they can be reviewed by the record owner.

I don't have a write up, but I really should put one together. Maybe that's the article I'll work on this week. You already described the main hurdle. When a user claims a record, you can't just migrate it to their repo. The DID, CID, AT URI all change.

Your record-level mechanism works at the cost of tons of app-specific logic to fixup an entire cascade of references -- when I update my references to reflect your DID change, that also updates the CIDs for my records too I admire you for the effort, but that's a lotta fiddly work for each app

The solution I decided on was: - create a new copy of the record in the target repo - create a redirect record in the old repo - delete the old record This allows apps to build around the idea that the data may move in the future.

The payoff: developers can onboard and claim their games. Platforms already using IGDB can migrate with relative ease. Games exist on protocol, developers own them, platforms can integrate.

That's the foundation. From there, we can start adding tons more functionality, but the core is in place: games on protocol, true ownership, and easy platform integration.