Enable arbitrary nesting of arrow operators

[jzelinskie]

The arrow operator can only be used once in an expression (e.g. org->admin), but should be able to support traversing an arbitrary number of relations (e.g. namespace->org->admin, tenant->namespace->org->admin->member).

This would allow for nested arrows in schema

[jzelinskie]

I just wanted to add documentation here that you can achieve this today by creating intermediary permissions on objects.
This is what we've been recommending and what lots of folks have used successfully.

For example:

definition token {}
definition user {
    relation access_tokens: token
}

definition team {
    relation member: user

    // Helper for documents to reach the access tokens
    permission member_tokens = member->access_tokens
}

definition document {
    relation writer_teams: team
    relation reader_teams: team

    // This expands to writer_teams->member->access_tokens
    permission edit = writer_teams->member_tokens
    permission view = reader_teams + edit
}

[yuhan-zhang-zip]

This can be implemented via introducing a intermediate schema layer. So developers can define multiple hops, like writer_teams->member->access_tokens. When spicedb server bootstrap, it could generate the corresponding intermediate permissions on objects so that the generated schema can work with the current system.

[birdayz]

Any plans to implement this?
Without, hierarchical relationships are really verbose and hard to maintain.

[josephschorr]

@birdayz Yes, likely as part of #1437, since it will involve schema changes anyway

[jorihardman-aumni]

We have a highly hierarchical relationship graph, and many of our most nested entities have permissions that are defined via relationships our users (subjects) have at the top of the hierarchy. In order to facilitate these highly-nested permissions, we need to build out a significant number of proxy permissions that aren't ultimately used by our application logic. Having nested arrows would allow us to only define permissions that we intend to use in applications which would greatly simplify our schema.

The existence of a permission implies that it will be used for domain decisions, and that's often not the case for our schema.

Contrived example:

Permission check of interest: nested_entity_3:some-entity-3#edit@user:some-user

# This is our subject 100% of the time
user {}

org {
  relation member: user
}

nested_entity_1 {
  relation owner_org: org

  # This is a proxy permission - it will not actually be used in application logic.
  permission edit: owner_org->member
}

nested_entity_2 {
  relation owner_entity_1: nested_entity_1

  # This is a proxy permission - it will not actually be used in application logic.
  permission edit: owner_entity_1->edit
}

nested_entity_3 {
  relation owner_entity_2: nested_entity_2

  # This is the permission we actually care about for domain decisions.
  permission edit: owner_entity_2->edit
}

But would be nice to have:

# This is our subject 100% of the time
user {}

org {
  relation member: user
}

nested_entity_1 {
  relation owner_org: org
}

nested_entity_2 {
  relation owner_entity_1: nested_entity_1
}

nested_entity_3 {
  relation owner_entity_2: nested_entity_2
  permission edit: owner_entity_2->owner_entity_1->owner_org->member
}

[thackerc]

@birdayz Yes, likely as part of #1437, since it will involve schema changes anyway

I see there is a preview version of composable schemas. Are you still hoping to include nested arrows at the same time?

[josephschorr]

@thackerc We plan to do it; composable schemas has enabled it, but it is not quite scheduled yet

[thackerc]

@josephschorr any chance this has been scheduled? Hope you don't mind the nudge.

[josephschorr]

@thackerc Not yet; we need to make additional changes to the schema system first, which have been blocked on some legacy systems we're currently fixing