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.

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

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.

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.

I also support those redirects transparently in the appview. If it receives a request for a migrated record, it will return the new record instead with a header that confirms the redirect.

The last thing is that I automatically update records from the app when a user logs in. Consider: - user A claims record A which has a reference to the AT URI of record B - user B claims record B Now the AT URI is incorrect. That's fine if the user is using the AppView, but not for other systems.

Basically, it's a complex problem that requires a multi-pronged approach, and even then you have to accept some trade-offs, like requiring apps that don't use the AppView to understand they may need to resolve redirect records.

Ah, you're brute forcing this without asking @bnewbold.net + @dholms.at for the AT equivalent of an HTTP 301 or 308 response Mad respect

Lol, that's exactly what I'm doing. I figure it'd require updating the spec and changing several PDS implementations. I want it to work right now, so... 😅