I'm curious if anyone has experience with "access adjacent" kind of cases which could be modeled in the graph. Is this a bad practice? If so, why? To be specific, we have a case where we have a notifications service where you can get notified about various events. For each event, you shouldn't get a notification for something you're not authorized to see. But you also shouldn't get a notification for something you don't want to get a notification about. So in doing prototypes, I found it theoretically worked very well to model both in the graph, where you have a resource with a permission like

view_notification = view & notification_subscriber

(where notification subscriber could be a synthetic relation with a subscription inherited from somewhere else in the graph). The team likes this because it solves an otherwise nasty query of potentially getting a bunch of users with access, and then having to join that with their own data on who is subscribed. (We could also easily do things like refer to other relations e.g. user groups when managing subscribers). On one hand, I don't see anything wrong with this – it seems to fit the underlying graph model very well. On the other hand one can argue it's not strictly access * so are we abusing something. Curious for anyone's thoughts or experience with this kind of situation :). \* I can actually think of this like access where you're authorizing your own "inbox" ... but perhaps that is too creative :).