Mitch VanDuyn

okay this is easier (I hope) than I thought. System never actually broadcasts count (i.e. client has to ask for it) So the semantics can be based on `acting_user` rather...

how about a `permit_count` method that takes a list of methods, and an optional block. If block returns true count is permitted. ```ruby class User < ApplicationRecord permit_count :orders {...

Thinking the above might not be `permit_count` but just `permit_relationship` and `permit_scope`. i.e. does count even have to be involved?

Another way to look at this is to say does acting_user have permission to look at the set of id's in the current scope. You could in fact implement count...

Some examples | query | acting_user == some_user | acting_user.admin? | acting_user.nil? | |-------|---------------------------|---------------------------|----------| | some_user.orders.all | good | good | bad | | some_user.orders | good | good |...

Fundamental to how relationships and scopes work is being able to chain them. For example, we might have the following expression: ```ruby Order.for_vips.with_positive_ratings ``` We cannot always tell if we...

Note that the regulations ONLY apply to requests from the client. Internal requests (such as arising from Controllers, or ServerOps) are as normal "unprotected" This means that probably the default...

@janbiedermann good points. I had already realized that by default we should assume that every scope is `denied!` this means that unless the developer has decided on some rule, we...

I like the default idea, cause it solves your new user problem nicely, and also makes the overall system easier to explain. The name should be `default_scope_regulation`. It can just...

Added https://github.com/ruby-hyperloop/hyper-mesh/issues/56 to cover UUID case