Post

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

main idea: - do permissioned data like you usually would (in your own database), but copy the structure (as close as possible) 1-1 from @dholms.at blogposts with the eventual goal of moving everything over seamlessly once permissioned data actually lands

- 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)

- 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

- 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)

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

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: