(This is another one where it's undoubtedly already been done, and done better, and I would value pointers thereto, but here's my version anyway.)


Here's what I'd like a online social network framework (e.g., a LiveJournal/Facebook/Dreamwidth competitor) to support:

1. Access control
   
   
   1. Reliable access control all the way up and down
      That is, I can specify groups of users and what each group can see/touch on the system. This applies not just to content (e.g., reading my posts), but to information about the network itself (e.g., being able to see who my friends are). I can specify this for a type of entity and rely that analogous security will be provided regardless of the mechanism of access.
      This includes sensible rules for handling access conflicts (e.g., user U is in groups A and B, A can read this post and B can't, can U read this post?). For example, give each group a priority and the best priority trumps.
      
   2. User groups defined in terms of other groups
      For example, if I have user groups "coworkers," "T@F," "Flat Earth." I can create groups "non-coworkers" and "theatre folks".
      
   3. On-the-fly user group creation
      For example, I can declare a particular post visible to everyone except George, and the "notGeorge" group gets created... I don't have to stop what I'm doing, go somewhere else, create "notGeorge," then come back.
   
   
2. Reputation/rating
   1. A ranking/reputation mechanism and associated filter mechanism
      That is, a mechanism whereby individual contributions (posts, comments, etc.) can be rated up or down by users, with an associated "don't show me things ranked lower than N" filter.
      
   2. Multiple axes
      I like slashdot's distinction between funny and insightful, for example. I'm not sure what axes I'd want... too many gets untenable, so parsimony is necessary.
      
   3. A recursive ranking/reputation mechanism
      That is, one where the weight of other users' post-ratings in determining what is displayed to me is itself based on the user's rating pattern. For example, if George generally rates posts the same way I do, then George's ratings are weighted high. If Sam generally rates posts the opposite of the way I do, Sam's ratings are weighted high and negative. If Pat's ratings are completely orthogonal to mine, Pat's ratings are weighted low.
      A weakness here is that new users don't have this data available; not sure how I want to handle that.
      
   4. Multiple weighting/filtering strategies (views)
      The example above is one possible view... "show me things people similar to me like."
      You could have lots of different views, though.
      For example, "show me things that people least similar to me like." Or "show me things people similar to so-and-so like." Or "show me things lots of people like." Or "show me things that many more people like than dislike." Or "show me things that lots of people like and lots of people dislike." Or "pick things at random." Etc.
      I'd like a little dropdown menu of preferred views, the ability to create new ones, and the ability to declare a view publically available so other people can use it.
      (This is a little bit like looking at someone else's friends page, but only a little bit.)
      
   5. Compound views
      For example, if I have two views, A ("things folks like me like") and B ("things folks most unlike me like"), the ability to create a third view that is mostly A, but every 20th item shown is B.
      
   6. Thresholds relative to volume
      E.g., if I'm looking at the comments on a post and there are five comments, lower the threshold for displaying a comment. If there are five hundred, raise it.
      
   
   
3. BOAF clusters
   That is, "birds of a feather." BOAF clusters are calculated automatically based on similar rating patterns, as above... people who reliably rate the same things the same way are in the same BOAF cluster.
   1. BOAF-cluster sampling
      E.g., if there are 500 comments on a post, provide a filtering mechanism where I see one or two comments from each BOAF cluster. So if fifteen people who tend to like the same things commented, show me just one of those (this works in conjunction with filtering as above; the highest-ranked commend in each BOAF given my current view is shown). Relatedly, allow a "track" setting for a post of "email me if a comment from a new BOAF comes along."
      
   2. BOAF-cluster maps
      That is, show me a high-level view of how many distinct clusters there are, and the number of users in each, and their activity level, and how far they are from each other in rating-space, and how tightly packed or diffuse they are.
      
   3. BOAF-cluster views
      Automatically create views (as above) based on average weighting within each BOAF, so I can get a feel for what the universe of discourse for that BOAF is.
      
   4. BOAFs and quiz memes
      In general I'm avoiding features that depend on understanding content, because that's a genuinely hard problem. But given the popularity and discreteness (if not necessarily discretion) of quiz memes, I'd like to see the BOAF clusters above tagged with question/answer pairs that characterize users in the cluster but not those outside the cluster, if any exist.
      
   
   
4. Sequence tagging
   Much of the above presumes a non-sequential access model... I can't be expected to have read "everything up to this point." But some content makes very little sense unless you read it in sequence (e.g., discussions in comments). So provide a mechanism to explicitly tag one entry as following from another (or from several others), and an easy way to say "show me the thread(s) containing this from the beginning."
   This includes threaded comments, but also things like "this post is a followup to that other post over there."
   
   
5. Optional "push"
   Like LJ's "track this" feature.
   
   
6. Distributed architecture
   1. The framework is a data model, an associated API, and a central registry.
      Any number of front ends to that API can exist, both GUI and programmatic.
      Any number of back-end data stores can expose that API; they register with the central registry.
      
   2. Users have unique IDs across the whole system (like OpenID), and every bit is expected to respect any ID. So a user can "reside" on one back-end but store data on lots of different ones.
      
   3. The central registry keeps track of unique entity IDs and the data stores that have registered as containing some of that entity's data, which allows a shared view of a user across back ends. This is not mandatory... it only knows what individual back-ends choose to share with it... but of course anything that isn't shared isn't visible unless the viewer already knows exactly where to look.
      So maybe my resume is on PseudoLinkedIn, my essays are on PseudoLiveJournal, my shorter updates are on PseudoFacebook, and I have a profile on AxeMurderers.com, and all but that last one are registered, so anyone looking for me gets the first three but needs to know to look for me on AxeMurderers.com. (This presumes I want it to be obscure but not necessarily secret. If I wanted secrecy, I wouldn't use my main ID in the first place.)
      
   4. There's no expectation that a real human has one and only one ID. That said, it would be good to allow a particular userID to be flagged as a real identity... a way for the user to assert (though not prove, of course) that really, this is them-in-meatspace.