Post

flo-bit
@flo-bit.dev

ive decided to just do a thread about the why's and how's of permissioned data in contrail instead of a blog post, cause i'm lazy, so here it goes: 1/9

flo-bit
@flo-bit.dev

- that means there's a simple ACL with read/write access for everyone in a space & people can create, list, delete etc spaces using xrpc endpoints - similarly record CRUD is as close to the normal putRecord, deleteRecord, listRecords, getRecords, etc xrpcs as possible (just with an extra space uri)

0 reposts4 likes

flo-bit
@flo-bit.dev

- auth works using service auth tokens (like bluesky dms) and contrail instances publish a permission set with all the xrpc calls for convenience, so other apps can access the permissioned data a user has access to too

flo-bit
@flo-bit.dev

- once permissioned data actually lands, the contrail instance slowly moves stuff over, your app just keeps using contrail for reading/writing and those get directed to the correct place (if already migrated a users pds, otherwise your db)

flo-bit
@flo-bit.dev

i'm not sure, how well that migration'll work (there will at least have to be a "dance" of permissions requested from users and passed to contrail and most likely the space owner will have to migrate first before other people that wrote to a space can move too), esp looking for feedback here

flo-bit
@flo-bit.dev

also added a few convenience things (a per-collection listRecords endpoint with filtering, etc that combines both public & private records (if authed) and a way to create and manage invites) and been working on groups (those might make migration easier too?) mostly based on @zicklag.dev's blog:

zicklag.leaflet.pubThe Arbiter - Group Management for Permissioned Spaces and Beyond - Zicklag's LeafletsThe permissioned data proposal has the concept of membership, but leaves it to the app to orchestrate it. The arbiter is our idea for a general-purpose, interoperable ATProto group membership service.