I don't know how much sense this will make to you, but I'll try my best explaining what I want in detail.

Personally, I find the package here pretty good to start with and I've used this package in version 2.0 for quite a while now. There are some things I want to address which would require quite some changes to this package, but I'm not sure if we should not collaborate instead of me just forking off and brewing my own soup.

I like the concept of having roles for everything, and this is also the part I would like to reuse in my package. Roles having nested roles, where each of them has a list of children containing the inherited roles. Even though I would not only include the immediate children, but also nested - but let's start from the beginning.

There are some limitations I hit which I need to do address in a different way.

I need to save the assignment of a role, which currently is stored in the property roles in the user document, in a separate collection to keep up with my performance requirements. Here's a list of reasons and features I need:

• Performance. The current implementation get's very heavy if you have a lot of resources where you want to grant or revoke access to a per-resource-basis.
• Publish a limited set of permissions published to the client. As the first point (Performance) already introduced, I have a pretty big list of resources. Not every permissions the user has is needed at any given time. I need to be in control which roles are published and which not.
• Attributes to an assignment. In some cases I need to save some metadata to an assignment. These could be saved in a collection introduced to address the previous two items of this list.
• Grouping resources. I have use-cases where I need to give users a role for a resource of a different type. Not hard, as my first idea was to just prefix the id with the document type. But I also need to be able to quickly find all roles a user has for a certain resource-type. A resource-group would make life a lot easier there.
• Search for the same role on multiple resources. Think of it as if the write-permission on a folder would grant you access to its files. The files are too many and tend to change rapidly. Some users now get permission on a per-file-basis, some for the folder, some for the full hard-drive.

To keep the first reason valid, I would also need to store the hierarchy of roles in the parent-roles, which would be the only change I see for the roles collection.

So, how does this sound? I think it justifies a separate package, but - at the same time - I would like to cooperate with you on a common basis so users could easily choose one of our packages, even if they only share the roles and all the methods there.

If you say that the differences of our ideas are not compatible, I'd go and brew something on my own and keep it separate from yours.