Well all the conceptualisation is interesting, but lets get practical. The first important idea coming out of the sprint is a Drupal way to enhance the 'private/public' idea in the system, the idea creates all kind of implication but I will restrict my post to how it has influenced the way we did create data. There is a strong relation with managing data I leave for the next post. There is also an interesting discussion on the nature of a groupagain it looks better to have it in a separated post.
One of the first things we would like is a private/public where groups can have some private content. At the moment you can write controle acess in several ways. Depening on the module or via the 'db_rewrite_sql' and the access-table. With the node_access we can't realy do what we want and the access-table is way to much of a "wild card" for our purpose. Now we really wanted a nice Drupal way to fix our problem, for one we my want to expand the public/private idea to the whole system (for example not only for groups but also for dyadic/contacts), meaning we should be handling it at the individual node level => node-table. At the moment you can find 2 fields in the node table 'publish' and 'moderation' and the two concepts are kind of ambigue at the moment.
Yesterday I had a interesting discussion with Dries about it, he suggested a system where you have an advanced moderation system (going to from creator to the photographer to the editor etc.). In our project we have created an advanced publish way to defined the access to the content (we see actually 5 possibilities: private, dyadic, group, registered and public). The two advanced features are making the separation between publish and moderation more explicit. I plan to suggest a patch asap to get the publish-option in Drupal.
The publish-option we have created has an interesting relation with 'audience' you all know from og. It became clear after experimenting with private messages and groups that the 'audience' is way more general and not restricted to groups. To make it practical let me give some cases to show how audience and publish-option is used in our testbed. Take 'private' it means you can only see the information, this is handy if you want to make notes or don't want to publish it yet. Now if you would put the public-option to 'group' without giving any audience to a group the group-publish would be similar to private-publish. If you take the case of a frontpage you would have an audience to groups but a publish-option bigger than groups (so public or registered; registered is only viewable for users, public if for every one).
At the moment the possibilities for a "content maker" are investigated. We see a more generic way of using audience e and publish and we only invesigated the viewablilty not yet the accessibility. So a lot of work is possible on it.
Comments
the dyadic content
The dyadic-publish has been investigated as a way of doing private-messages with nodes. Now it became clear (we didn't do any test with this yet) that the private-message is a publish-option set to 'dyadic' with audience to the contacts. (ok its a terrible sentence) Notice if we abstract the concept we have two implications. First every type of content would become a possible carrier for a private-message creating a dyadic space as we have a group space (I hope you can see the possibilities of it).
The second implication is we get a richer way of communication. For example, take the classic private message (but as described above) and add audience to groups as well; this would be interesting as the users is now aware the private-message is related to the context of a specific group. I hope you have noticed the hierarchy in the publish option (private < dyadic < group < registered < public), the hierarchy has interesting consequences. I can audience a post to a group and add some contact not in the group to it as well. In a way it opens a more natural way to grow into a group by getting attracted by one of your contacts. In this way audience is getting a very specific meaning. We see it as related to free-tagging where the difference is audience is made by the publisher and free-tagging is maid by the reader (for free-tag I will create a new post).
Any combination has a value, you can post something public and give audience to contacts and group, thereby you are actually 'networking' and making it visible for any one who comes to the content. If we could make some good generic tools to visualise the relation (see radar post) the idea of networking by publishing could boom the content creation. Of course we are looking at all ways to manage this to avoid spamming, rating (like the e-bay style) is definitely one of the paths investigated.
Trying to depict my ideas
The idea that one can publish private, dyadic, group, registered or public for all kind of contents is brilliant.
The part of being able to make extern contacts (from externs or from other groups) is, I believe, also essential.
That readers can give free-tags is a way to give the contentnode a place in its network maybe (and gives the structure?). Rating by the usefullness for those who opened it, as feed back seems a good option.
Some further trying of setting my mind:
http://homepages.vub.ac.be/~eimatthy/CMap/NodesInSpaces.html
In a practical approach I
In a practical approach I would suggest that any instance above dyadic has to be a Drupal access role. Your pathway should look like this:
private < dyadic < group < roleXY < registered users < anonymous userswhereas "group" refers to organic groups in my opinion.
Regarding the investigation of rating, contents are probably best 'digged' by every user. eBay style is not very amazing and not worth looking a in concerns of knowledge management.
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
I highly recommend you check
I highly recommend you check out the na_arbitrator.module which contains acl.module which is already a step toward what you seek.
There is some talk about trying to rewrite og to rely on something like acl, and I am pushing to get the na_arbitrator portion actually in core; acl can then be its own API.
checked te module
It is good some one has been working on access. I notices you have been working on top of 'node_access' and 'grands'. Personally I think the 'node_access' and the 'grands' are some ugly hack, probably after some bad compromise. Forgive me If I'm wrong, but that is how it looks to me (as a new developer). I think your model is a good proof of how complicated the grands and node_access become for powerful usage of access control and we do need a module like yours if they want to go on with the 'node_access' and grands' (like stated in the module, its a glue between node_access and other modules).
There is another way to work on it, one involving way less checkups (reducing the lookup time for access) and at the same time it could clarify the difference between two features in Drupal, the 'moderation' and 'publish' option (where publish is called status in the DB) as explained above.
If we would follow the information-flow needed to check access, notice you have to do it in nodeapi, but than you need to check all modules again. Just turn it around, when you check for node_access call a nodapi with in it. It makes it all so much clearer, I just expanded the 'status' (next to public/private the option that suggest to check groups or contacts for access control). Well its all very fussy if you can't see it, we should try to push back all our development to Drupal. I hope to do the push-back in the coming weeks.