yarffaJ nalA (jnala) wrote in lj_dev,
yarffaJ nalA
jnala
lj_dev

Refactoring friends

The "Friends" concept is overloaded. It contains "people I'm watching", "people who may read my protected posts", "people who can post to this community", and "people I'm warm and fuzzy about and want a link to".

It is also inflexible. Some people want to be notified whenever their name goes on or off someone else's Friends list. Other people want to be able to reorganize their friends list without sending dozens of people into a tizzy.

Friend groups solve both these problems. Friend groups can be either public or private (not yet implemented, but support is there), and you can view or give permissions to different subsets of the total group of friends. The problem is this: No matter how easy it becomes to use friend groups, the default will still be your entire friend list, and that will still be easiest.

Put that way, the solution becomes easy. Give every user two friend groups with standard names. One is the default group for viewing one's own friends list. The other is the default group for allowing others to see your protected posts. These groups are undeletable, and are private by default. All new friends are added to them by default. The main friends list is used for providing the pool of friends which can be added to the subgroups, and for the warm-fuzzy-link purpose.

For many users, this will result in no visible change. Someone who doesn't want to mess with friend groups will continue to add and drop friends, and things will work as normal. For other users, it can provide significant extra ease of use and flexibility. It also opens the doors for future added features which would otherwise overload Friends even further.

Implementation is relatively straightforward. Add deleteable and add_by_default columns to the friendgroup table. Reserve a couple of bits for the systemwide groups, and turn them on for all existing friend relationships. Add the system groups for all existing users. Then go through the code and replace references to friends with references to friends in group [whatever].

Open issues:

What should the new system groups be called?

We only have one bit reserved; is anyone actually at the maximum number of friend groups, or can we go and reclaim a few more bits for this purpose and future expansion? We could expand to a 64-bit field or two 32-bit fields if necessary, but it'd be nicer to just grab a few more bits from the existing field. Someone with DB access, go run "select groupnum, count(userid) from friendgroup group by 1 order by 1" and tell us the results...

Thoughts?
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 42 comments