Initially we had the "friends" table which contained all the people you watched on your friends list. And these same people could all read your "Friends only" stuff (ignoring custom security).
Many parts of LJ don't offer custom security, only "all / registered / friends". So there's no way to watch a journal and not give them access to read your memories and text message you, for instance.
That problem is easily enough solved: bit 0 in the groupmask in the friends table is always set. If we let people add "friends" with that bit off, we just have to modify LJ::is_friend(...) to check that bit in that row, rather than the mere presence of the row. Easy, and no slower. Complication: updating clients and deciding on good wording everywhere.
So at this point we have two types of edges: watching and befriending.
And soon we'll have trusting. I trust a lot of people that I don't care to read and don't want to read my stuff.
So do we store that in the friends table still? Do we want more metadata on trust edges? Like date certified, say?
I'd like to put trust stuff in a different table, for a number of reasons. New tables tend to change for a number of months after their inception. I don't want to be modifying the friends table often, and I don't want to bloat friends later. And I don't want everything that requires scanning all of a user's friends to have more data to scan.
Anybody feel like taking on the project to separate friends/watching? Another issue: the "Default View" hack. We have the "showbydefault" enum in the friends table which we're not using it. Is the "Default View" solution good enough? Should we drop the showbydefault column and save some space? Or should we turn the showbydefault enum(1,0) wasted byte into a real byte so we have 7 more bits to use for other things?