NIP-29: define explicit role permissions and access schema on kind 39003

[1amKhush]

This PR scopes to NIP-29 only (per coracle/flotilla#47) and centralizes role semantics on kind 39003.

Changes

• Clarifies authorization model:

  • permissions derive from role-permission
  • role names and role-order are non-authoritative for moderation capability

• Extends kind 39003 role schema with:

  • role
  • role-label
  • role-color (hue 0-255)
  • role-order (UI ordering only)
  • role-permission (explicit privileged 9xxx kinds: 9000, 9001, 9002, 9005, 9009)
  • role-access (read/write/join)

• Tightens assignment/listing behavior:

  • 9000 assignments referencing unknown roles MUST be rejected
  • 9001 removal SHOULD clear role assignments for that group
  • 39001 is explicitly informational, not source of truth for authorization
  • 39002 members MAY include role names after pubkey for client UX

• Adds compatibility guidance:

  • group-level 39003 remains authoritative for group validation
  • if inheritance exists internally, relays MUST materialize resolved roles into group 39003 for NIP-29 interoperability

  [NIP-43 follow-up tracked separately: https://gitea.coracle.social/coracle/flotilla/issues/192 ]

[staab]

ACK

[1amKhush]

@staab

[fiatjaf]

I can't really read everything but looks good.

There is an ambiguity though: if I create a group and give delete-user permission to someone else, can they delete me? Or if I give them permission to delete-event, can they delete my events?

[1amKhush]

@fiatjaf

This behavior is relay policy. If a relay wants founder protection or hierarchy rules (for example, cannot moderate equal/higher roles), it should enforce that locally.

Also as i understand NIP-29 does not define a protocol-level creator/owner who is automatically protected. So if a relay grants someone remove-user permission, they can remove any member in that group, including the person who delegated that permission. Hence in the current proposal, permissions are capability-based, not target-scoped.

Though I agree we should add a clarifying note so this is explicit and not ambiguous.