Most LJ features are harder because of the social issues than the technical ones. This may be simply because bradfitz, etc., are skilled programmers, but it's more likely because the social issues are just plain harder. I think a significant part of LJ's success has been the sweet balance between features and complexity, and keeping that is difficult.
here are the issues to address:
- user interface:
what would the ui for it be like? when i subscribe to a user, how do i select which categories to read? how do readers learn of a new category that is potentially relevant to the category they're reading? how do we do this without breaking existing clients? how do we display the categories you're subscribed to on a given user? can i do negative subscriptions-- specify i want to subscribe to all of jens's categories, past and future, with the exception of some category #c? how about positive subscriptions? how do we display this data on the userinfo page?
are categories mutually exclusive, or can i post something in multiple categories? how about subcategories? how do readers subscribe to [n] categories on a given user-- is that n subscriptions, or n sub-subscriptions on a single user? how do friends-only posts work-- if i friend your #foo category, can you read my #bar friends-only posts? how do categories affect the urls for a post-- are all posts still in a flat numeric namespace? can the existence of a given category be made public/private? how about friends-only categories? (what could it mean for a category to be friends-only?)
where would the per-post category information be stored? the database tables are too huge to be able to add another column, so it'd have to go into the "arbitrary properties associated with a post" table. would that slow down building friends views, because we'd have to query another table? i'm not sure; there is also the "backdated" property that affects friends views, but that may work through a hack. even if we could retrieve efficiently the full category information, is there a way to efficiently test whether user u1 wants to / has the security clearance to read user u2's post p that's in category c with security s, given the multiple possible friend relationships between u1 and u2 (potentially u1#cn--u2#cm, worse with negative subscriptions).
to summarize, i'd say: if you could make a solid proposal that addresses all of the social/user-interface/not-confusing-the-p
(Also, be advised I'm not intimately familiar with the friends code, so I may be missing some big things... I just figure I've worked with other LJ features enough that I can take a stab at what the issues with it might be.)