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.

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.

0 reposts1 like

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 goal of a DID-level mechanism is to keep as many AT URIs intact as feasible, at the cost of a fixed additional implementation burden in two spots: - PDS implementations - DID resolution caches However, this migrates entire identities, rather than just selected collections or records

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.

So when a user logs into the app, we automatically update any records they own which have references to redirects.