Previously, we described a separate mechanism for establishing shared visibility into the same House Dice permissioned space for two different player accounts. The game has now been updated to allow players to create that shared visibility themselves, via a permissioned space toggle in the settings menu. Below is a summary of how that loop was closed, as written by my computer helper.
Report from Computer Helper
In part 1, we confirmed that the underlying mechanism for mutual visibility — one account reading another's data inside a shared permissioned space — actually works against the hosted alpha PDS. At the time, that was all it was: a confirmed mechanism, tested through console commands, with nothing built into House Dice's actual interface.
That's no longer true. All six games in House Dice now have live mutual visibility, and the full space-management lifecycle — creating a space, adding a partner, removing one, listing current members — is wired directly into the app itself, through a real settings screen. No console, no external tools.
Three things came out of actually building this for real that seem worth passing along to anyone else working against the alpha.
A space credential grants the whole space, not one piece of it. Once minted, the same credential covers reading every collection in a shared space — we never had to mint a separate credential per game. If you're designing your own space and want genuinely separate audiences for different pieces of data, that has to happen as separate spaces, not separate collections inside one shared space. The protocol's access boundary is the space itself.
createSpace has no natural trigger during ordinary use — until suddenly it does. Reading and writing your own records in a space works fine without ever explicitly creating it; a PDS seems to provision that implicitly the first time you write. The moment that stops being true is the instant someone else tries to gain member access — getSpaceCredential looks up a real, registered policy configuration that implicit provisioning never actually created. In practice, that means the cleanest place to call createSpace isn't at setup time at all — it's reactively, the first time an addMember call fails with SpaceNotFound, immediately followed by a retry. That "ensure, don't pre-provision" pattern turned out to be exactly the right shape for a feature that most users may never touch.
The full admin lifecycle held up cleanly under real use. Create, add, remove, list — all four worked immediately and consistently, with no batching, no propagation delay, nothing surprising. A member removed from a space is genuinely gone from that space's next credential check; a member added is immediately eligible. For infrastructure that launched a matter of days before we started building against it, that's a good sign.
A companion reference script
Same spirit as part 1's script, covering the other half of the mechanism: here is part 2's space admin lifecycle reference script — createSpace, addMember, removeMember, listMembers, and the reactive "ensure membership" pattern described above.
Thanks
This project relied heavily on community research, documentation, and outside tools along the way. Much appreciation to everyone involved with this effort.