Historically, we've used "friends" for everything, and it's currently pretty overloaded. It currently means:
-- who you read (except with the "Default View" friends group hack)
-- who you trust (by default, with "Friends only", unless you make custom security groups, but not everything supports custom security groups)
-- who you know well online or in real life.
-- who you list on your userinfo as being your "friend", which can mean any subset of the above three reasons.
It's also used for community membership, in some cirumstances. The community account befriends trusted members, who can read friends-only posts. But watching a community or having post access to it doesn't necessarily mean the community trusts you back.
Now, the situation started to improve when we added the "reluser" table (user relation edges), which let us drop a lot of other tables: ban, logaccess, etc. But that was just the start.
We want to start both clustering and memcaching user relations (with the complete edge being stored on two clusters, and only half indexed on each side), but before we go ahead and port the existing system's structure and reproduce it more efficiently, we've been thinking it'd be better to start discussions about its current limitations and how we might clean it all up.
Current limitations as I see
-- should have a distinction between read, trust, and display on userinfo page. The default would probably be to add all 3 when befriending somebody, but you'd have the option to disable some aspects of the friendship.
-- should have a way to hide your membership from certain sensitive communities on your userinfo. this is almost the same as above, but it involves hiding certain "friend-ofs", as the system is setup now. that's because it's the community that's trusting you back, or giving you access to post in it, which are currently shown on userinfos now.
Fear in changing system
-- breaking down the community aspect of the site. As such, the defaults will continue to be as they are now, and people will have to take actions to not trust or not show peoplke.
-- we don't want friendships to become complicated, so I propose keeping the UI simple. everything's still "friends", but there are just properties on friendships (as far as UI is concerned).
Open questions
-- With 3 forward edge types, what "-of" types do we shown on userinfo pages?
Trusted by?
Read by?
Friend of?
My vote is just "friend of", which has no meaning other than display. I think who you read and who you trust should be private.
-- When user A looks at user B's friends page, what set of users do they see? The "friends" instead of the "read" group? (which is what currently happens, actually, since only the owner of a group sees their "Default View" group....)
-- DB representation. clustering/indexing/memcaching.
-- What's searchable, what's not? (via directory/API) I'd say just the display edge.
Need Project Organizers
What I want is a group of people to spearhead this discussion and maintain an ongoing proposal/spec for changing it all. Any volunteers? Ideally the group would involve geeks like who know the code well, as well as people thinking about preserving the community, and also privacy advocates, who want to use a tool (LJ as aggregator/client) without the world watching exactly how they use it.
← Ctrl ← Alt
Ctrl → Alt →
← Ctrl ← Alt
Ctrl → Alt →