Yeah, the basic issue here is that we don’t compile auth rules into other auth rules. There’s two reasons for the current behaviour: firstly, to make each rule ‘self contained’ so that you don’t need to understand all the rules to understand a single rule, and secondly because it’s pretty easy to get into recursive situations where rules depend on each other in a cycle.
The initial plan was that because the rules are all GraphQL, we’d move towards being able to upload a .graphql operations file with the schema. That way you could define the rules in the operations file and because the file is GraphQL operations, you can use fragments etc to build the rules from parts, rather than rewriting everything for each rule.
That alone should solve lots of the repetition problems (and give you syntax checking, GraphQL type awareness etc in writing the rules).
Personally, I prefer to look at that as a solution than to add further directives. It’d work out effectively the same - e.g. instead of contact @authRules { id } you’d define for example a contactNotDeleted fragment and write ...contactNotDeleted. I think it would work out the same kind of expressive power and keep the rules a single statement, rather than depending on each other.
@amaster507 what do you think - can we cover you use cases with that sort of approach?