at://did:plc:44ybard66vv44zksje25o7dz/sh.tangled.feed.comment/3mybcv3fznv22

Back to Collection

Record JSON

{
  "$type": "sh.tangled.feed.comment",
  "body": {
    "$type": "sh.tangled.markup.markdown",
    "original": "Overall I like this direction a bunch: reusing atproto permissions and regular record CRUD as the interface. feels \"atmospheric\".\n\nI suspect that we are going to need to constrain / lock-down the permissions and role hierarchy some more.\n\nFor example, we probably need to prevent \"abdication\" of all admins, and that gets complex when \"what is an admin\" is configurable.\n\nDo we want to open up all the non-space permissions to roles? Presumably it is a feature that creation of public records on behalf of the group can happen. What about `rpc:` (service auth)? Or updating the group account handle? What about requesting service auth tokens (JWT)?\n\nProbably worth having a separate security-brained review of the role/permission/scope system to make sure there are not tricky ways to escalate permissions by writing/mutating space records.\n\nDon't need to get in to it now, but the space label setup makes me wonder if we should have an OAuth scope for \"regular\" labels. In that signing label objects is basically an \"atproto resource\" that you might delegate permission over.\n\nWe should define what role/permission is needed to do basic \"authn-only\" OAuth on behalf of the group (aka, to do two-sided OAuth at all).",
    "text": "Overall I like this direction a bunch: reusing atproto permissions and regular record CRUD as the interface. feels \"atmospheric\".\n\nI suspect that we are going to need to constrain / lock-down the permissions and role hierarchy some more.\n\nFor example, we probably need to prevent \"abdication\" of all admins, and that gets complex when \"what is an admin\" is configurable.\n\nDo we want to open up all the non-space permissions to roles? Presumably it is a feature that creation of public records on behalf of the group can happen. What about `rpc:` (service auth)? Or updating the group account handle? What about requesting service auth tokens (JWT)?\n\nProbably worth having a separate security-brained review of the role/permission/scope system to make sure there are not tricky ways to escalate permissions by writing/mutating space records.\n\nDon't need to get in to it now, but the space label setup makes me wonder if we should have an OAuth scope for \"regular\" labels. In that signing label objects is basically an \"atproto resource\" that you might delegate permission over.\n\nWe should define what role/permission is needed to do basic \"authn-only\" OAuth on behalf of the group (aka, to do two-sided OAuth at all)."
  },
  "createdAt": "2026-10-20T02:52:48+03:00",
  "pullRoundIdx": 0,
  "subject": {
    "cid": "bafyreifez54dvaehbsqmsvdcb2jc7rlch4dduvigtr2di4jd4rcbuiqure",
    "uri": "at://did:plc:epbi6paber3mxm7237xkwvj5/sh.tangled.repo.pull/3mxfm26mw5422"
  }
}