Conditions on concentric relationships

[netthier]

I believe being able to specify conditions on concentric relationships that depend on the context of the relation they're pointing at could be useful, i.e.:

type foo
  relations
    define can_bar: [bar]
    define can_baz: can_bar with my_condition

condition my_condition(pass: bool) { pass }

with the behavior:

tuples:
  - user: bar:a
    relation: can_bar
    object: foo:b
    condition:
      name: my_condition
      context:
        pass: false
tests:
  - name: test-1
    check:
      - user: bar:a
        object: foo:b
        assertions:
          can_bar: true
          can_baz: false

One possible, though admittedly slightly contrived usecase could be:
Let's say I want to model permissions within a group.
There are three types of groups:

1. Private groups. Every user is automatically the member of one containing only themselves. No other members can be added and the group cannot be left or deleted, but documents can be created within the group
2. Built-in groups. Users may be invited and kicked from these groups, and they can create documents as well. However, the group cannot be deleted
3. Public groups. Same as built-in groups, but they can be deleted

To do any action within a group, the user must have the corresponding global role.

Using conditions, this could be modeled like this:

type user
type system
  relations
    define group_can_delete: [user],
    define group_can_invite: [user],
    define group_can_create_doc: [user, user:*]

type group
  relations
    define system: [system]
    define member: [user]
    define can_delete: member and group_can_delete from system with group_kind_deletable
    define can_invite: member and group_can_invite from system with group_kind_invitable
    define can_create_doc: member and group_can_create_doc from system

condition group_kind_deletable(kind: string) {
  kind in ["public"]
}

condition group_kind_invitable(kind: string) {
  kind in ["built-in", "public"]
}

where the kind context would be carried by the group->system relationship.

Partial polyfill

In cases such as the one described above, a polyfill is technically possible via self-referential "marker" relations, e.g.:

type group
  relations
    define system: [system]
    define member: [user]
    define is_private: [group]
    define can_delete: member and group_can_delete from system but not member from is_private
    // etc.

However, this quickly gets messy and difficult to understand once more markers are added (which is very suboptimal for authz models), and doesn't work at all with more complicated relationships.