"Short circuiting" for rules with intersection operators

[lupeterm]

Hi all,

Lets assume this small example:

type event
  relations
    define limited_to_group: [club, team, branch]   
    define can_view: [user, user:*] or member from limited_to
    define follower: [user] and viewer

The idea is that a group can host an event, which is only visible to their respective members. Additionally, interested members can decide to follow this event to get updates etc.

It is currently possible to create the edge user:tom follower event:party, even if tom is not a member from the group.
This has little to no semantic effect. as checking if tom is a follower of party would return false because the unsatisfied member relation.
However, this feels a little counter-intuitive - Why would it be possible to create the follower edge for someone if they don't satisfy the somewhat "preceding" relation?

I realize this would likely decrease the performance of write's but maybe there is an alternative that I've missed that avoids the insertion of unnecessary edges without killing performance?

[dyeam0]

Hi @lupeterm

Thanks for starting a conversation. You make a good point. Managing redundant tuples is an important consideration.

The main concern with building this validation into the Write API is the significant performance and operational complexity it would introduce. As you noted, this would directly impact write performance. To enforce such a rule, every Write would effectively require a preceding Check to validate if the relationship already exists indirectly. This would add significant latency to a critical path.

There's also a more complex issue when the authorization model changes over time. Consider this scenario:

1. An admin wants to ensure user:tom can view doc:1, so they attempt to write the tuple (user:tom, viewer, doc:1).
2. The system blocks this write because user:tom is already a member of group:eng, which has the viewer relation on doc:1.
3. Later, an admin removes user:tom from group:eng.

Now, user:tom has unintentionally lost access to doc:1. The original admin's intent was for Tom to have access regardless of group membership, but the system's behavior prevented that. This makes authorization management brittle and the outcome of a Write dependent on the system's state at that exact moment.

I think a better idea may be a "clean up" tool. An offline tool could periodically audit and remove redundant tuples. This would provide these benefits:

• It's an intentional operation, run by an administrator.
• It doesn't affect the performance of Write and Check APIs.
• It avoids the complex and unpredictable behavior tied to real-time state changes.

[lupeterm]

Hi @dyeam0

Thanks for replying!

Your point is absolutely correct. However, you're talking more about the redundancy of edges, while I (at least intended) to talk more about avoiding non-redundant, but "useless" edges.

I guess my primary motivation is my initial confusion that I can create edges where the logical term in the relation definition evaluates to false.

The clean-up tool seems like a great idea that would solve both of our problems 👍