Social Networking Unified Access Library. A new and better approach?

I submitted this within the forums, but I don't think it will get the attention it desires... I think this is an important step in development in Drupals Social Networking... Take a look and see if it is something that will draw the attention and the enthusiasm that it deserves. If it is deemed usable, then I will start working on an API.

I have found that a number of application ("Organic Groups", "BuddyList") all form user<->user relationships. The problem I see is that there is no fundamental library for such applications. A basic Library, that would unify the relationships of users. This goes beyond a simple user relationship database, and must incorporate, simplify, and focus the node-access routines, so that limited access can be granted on a base set of rules. This would make such development easier by avoiding the complexity of the security system.

Development of such a library would uniform the access and utilities of such social applications. The next building blocks would be to incorporate it into everything from views, OG, Buddylist, Blogs, and any other module where the developer feels its necessary.

Requirements:

Many to Many table with UID: Trace User ID's up to the access level granted, or trace the node/view up to find all users that belong together.
Access: Ability to set access permissions based on individual (UID), The last access based requirement makes things more difficult but much more flexible. Basically allow the module we develop can be used to create a group that can control another group of people (aka inheritance). Inheritance may not be needed because each node/cck could be assigned a setting that would verify their ability to edit the content, and the actual editor could use this API.
Security: We must make sure that core Drupal functionality (like Search, publish, etc) would prevent those that don't have access to not see the content. The inevitable results could be a dynamic home page that shows additional content previously un-viewable after the user logs in. The requirement, implications, or additional functionality of such a result must be debated.
Access level (anonymous user, authenticated user, admin or defined): Maybe universal and not sectional. I beleive this to be the case, though you might be able to come up with an example were it maybe required that multiple settings are given on a single page. I dont beleive this to be the case, so I think the default "Access Control" section of the site maybe the best. For more advanced control, content_access maybe used.

Additional Feature List Needed. We need this flexible enough to be used in: Buddies List and Organic Groups. The requirements of Organic Groups is of particular concern do to my lack of complete knowledge of how the administration, and levels works. We also should allow for a variety of cck based fields that will allow for the user to implement his security clearance within the documentation creation process. I beleive this is both a cck and a views hook. Other applications may (and will use) this.

Examples of usage: would be to build a blog that would allow your users to set access to a specific entry to "friends" only. Another feature would be "private" access which would allow someone to develop a document over time and then change the access to "public", however this would be flexible to encorporate into the intranets, and use terms like "Accountant", etc...

Logic: In code we either pass the security check or fail. There is multiple types of security settings, but the actual concept of security is rather mundain. My idea is that every user has access to their resource, the over riding forces are the moderators, and thoose given access through traditional means. In an organization with Accountants, Managers, Maintnance Crew, Publishers, etc... their maybe a need for an additional table that gives Inherited properties, with bonus's. This would allow for each end user to be able to be in control of a section of individuals and their work. The current model does NOT do this, but a few adjustments (I think 1 table) will grant such an ability. Either that or use the natural hiarcial style within Taxonomy, and incorporate it within an administration tool, that can manage this relationship. Then also incorporate it within the AccessSetup_Permissions page.

Definition Tables

//Setting Up the Control
AccessSetup_Details General Label, Type of Access, Description, Details... used in a few tables.
AccessControl_Details_ID
AccessControl_Title
AccessControl_Description

AccessSetup_Permissions_Resource This collection willgroup user permission from the AccessSetup_Permissions page. Building a list. The node or control will be assigned the AccessSetup_Permissions_Resource_ID.

AccessSetup_Permissions_Collection_ID //arbritraray unique Identifier
AccessSetup_Permissions_Resource_ID
AccessSetup_Permissions_ID

AccessSetup_Permissions This will assign the User control Permissions... it maybe great to use the Taxonomy collections for this, and add the following details for security on applications.

AccessSetup_Permissions_ID
AccessSetup_Permissions_Resource_ID
AccessSetup_Details_ID // May replace with Taxonomy.
Permissions <-- Need a Read, Write, Assign, and Manage.

Read will give access to thoose down the chain access to view the material, write will give them the ability to write content, assign will give permission to Assign the access to a User Group, and Manage will allow people to manage who is in the group.

AccessSetup

AccessSetup_ID //ULTIMATE REFERENCE NUMBER FOR PERMISSIONS! This number is provided by the module writer, when a new one is needed. Often times, every user may have one. must be unique.
AccessSetup_Permissions_Collection_ID
AccessSetup_Details_ID *for use in CCK, and other developments, explains the control (drop down, multiselect textbox, etc), what it does, and how it works.

User specific Tables

//Creating User Relationships

UID_Link Defines relationships between users. Very simple. UID's are not Parent Child relationships. They are single dimensional, I did this because I dont think a Parent Child Relationship has a valid usage

User_Permissions
User_Permission_ID //arbritraray unique Identifier
UID //who is the owner of the resource, Multiple UID's will exist for each resource they have access to.
AccessSetup_Permissions_ID //What permissions do they have...

Here is an example SQL statements: of course a class should be built that will handle these calls... more SQL too come

SELECT User_Permissions.UID FROM User_Permissions, AccessSetup, AccessSetup_Permissions, AccessSetup_Permissions_Collection WHERE AccessSetup_Permissions.Permissions = %X% AND AccessSetup_Permissions_Resource.AccessSetup_Permissions_ID = AccessSetup_Permissions.AccessSetup_Permissions_ID AND AccessSetup.AccessSetup_Permissions_Resource_ID = AccessSetup_Permissions.AccessSetup_Permissions_Resource_ID;

//This is essentially all SQL statements, but in particular this one is looking for all users who has %X% permission... add a "User_Permissions.UID=" and if empty your user is out of luck (no Access). Take out "AccessSetup_Permissions.Permissions" = %X% and add "AccessSetup_Permissions_Resource.AccessSetup_Permissions_Resource_ID = %X%" where X is the resource ID and you get all people who have access settings to this resource. I will write out more examples in the future...

I can write the SQL statements, and some of the code, I have very little experiance with any code (other then BuddyList). I do not know the API's yet, but I guess Im going to be tossed into it. I would love to have a detailed working plan before I start... I hope Its clear... What I am unsure is what to do with the access list once I have it... how to put it into the site security, and also have to come up with different elements that utilize the API I create. It will be simple Add user, Check Permissions type class... I figure that is a good place to start.... if I can then hand off the API I make to someone who can impliment the site security side, or if I can get help, we will have a valid API to work from. Then we just need people to use it... All admin functions should be done on the page, rather then within the admin section. This DB can get rather larger, beign that each user who joins a buddy list, can get many records. Indexing is a must.