Greetings - I don't generally post here, but I read your comment re: social networking and I didn't want it to fall through the cracks.. . so I just wanted to give you a little bit of (hopefully helpful) guidance, regarding which direction to take, in case you're looking for some. On dev / your 5.26.06 posting / it seemed as if you were trying to decide whether to go for developing either... (1) "social networking" capabilities, a la orkut -- for drupal end users -- (2) or network analysis -- for drupal admins. Personally, my vote is for polishing up the social network capabilies of drupal for end users, a la orkut. [In fact, (1) might be a prerequisite for a successful deployment of (2). Reasoning: without adequate SN capabilities, there might be little network infrastructure to analyze.] :-) Anyhow, that's my current interest and bias and in case you've elect to go that route, I've done some investigating of what drupal already has on offer, so could hopefully give you a bit of a head start. There's definitely stuff you can build on, although there's also quite a ways to go. The principal social networking tool available in Drupal, imho, currently, is Drupal's "buddylist.module" which is supposed to be the rough equivalent of the common "friends" function you find on all the popular SN sites, orkut, myspace, etc. The module is well written and well documented. So, I would consider building off of it. However, this module has two significant drawbacks, (1) First, under its current cvs setup, *buddy relations are not symmetrical*. That is, if A is buddy of B, it does not imply that B is buddy of A. That is, buddylist treats friendship relationships as *directional*, rather than *mutual*. This creates some confusing scenarios -- for example -- under the current setup, you can have the following situation: "Jack is buddies with Jill, but Jack is not buddies of Jill, where as Jill is not buddies with Jack, but Jill is buddies of Jack" [Did you get that? ;-)] Although there might be some very unusual special cases where a unidirectional friend relationship might be useful, this is clearly, generally, not the common semantic case. (2) Second, currently, *buddy relationships may be unilaterally determined*. That is, A can unilaterally decide to declare that he is buddies with B, regardless of B's consent. That is, for example: "Quasimodo, the crazy stalker, can decide *on his own* that he's buddies with Esmerelda, even though Esmerelda has placed a restraining order on Quasimodo." Again, this unilateral capability is not standard in the common usage of buddy relationships as a social networking tool - and for good reason, I believe. Generally, buddy relationships are mutually and *consensually* determined. There are other more superficial issues regarding the polishing of buddylist, but these two issues strike at the core of it, and should be tackled first, imho. A solution to these two issues above has been posted as a patch here http://drupal.org/node/11892 -- it is patch that I wrote -- with help from RobRoy -- and functions without a hitch on my site, www.ithou.org . This patch replaces the "asymmetric" / "non-consensual" framework with one that is "symmetric" and "consensual". It is still awaiting review. I imagine that you could assist in that polishing and review process and as part of your SoC contribution, you could help move Drupal and buddylist into a more solid social networking platform. Should this be of interest to you as part of your SoC project, please do not hesitate to contact me. Regards, Albert albert [at] ithou.org