One of the more complicated aspects of MyColts.net to implement is what we're calling friendlist security. It allows you to control different views of your content and profile based on groupings you setup. It gives you full control over who can see what information that you publish. Thus, if your boss were to checkout your mycolts.net profile he may indeed see a completely different version of your content than your friends.
To make this work we started with a role based security system controlled by each user. It is a classic create groups, put users into groups, and then assign permission to the groups scenario driven by each user. Different components of the system (calendars, blogs, comments, photos) etc then plugin to the role based security system to govern the overall content and who is allowed to see it. The UI relies on knowing the friendlist assignments by the content creator and comparing it to the intersection of assignments given to the current person viewing the content.
The implementation involves a single Permission entity. That permission entity has a globally unique identifier (GUID) on it. The GUID is stored along with the entity that owns the permission such as a blog or photo gallery. When the permissions are edited the GUID is then joined to the permission list table for all of the profiles, friendlists, and groups that have been assigned rights to that content. When there are no permissions assigned we set a bit flag indicating public permissions so that the rest of the permission checks can just be avoided if it is considered public content. Since it is a social networking site we decided to use least restrictive rather than most restrictive on default permissions to try and encourage folks to share content. Since all permissions are stored in a single set of tables we have a single control that can be used to edit the permissions on any entity type. You simply bind the control to the permission GUID and it will allow you to edit and maintain the permission assignments and persist them back to the database.
There are a couple of joins required to check permissions on any entity, but so far the dynamics and flexibility of it have off set any performance issues. Not to mention we've indexed the heck out of it. It has proven quite a challenge to test. There are individual, friendlist, and group assignments to consider. Any number of times we've been convinced we found a problem only to find that a user was a member of a group we didn't realize had permissions that was granting them access. I'd heavily encourage anyone trying to build something similar to have some very explicit and detailed test cases to save yourself hours of headache and chasing phantom problems.
