The specific design concept that only members of a discussion can review the discussion. This is intentional - it at least allows people the knowledge that some specific set of users can be reviewing what they said.

This can lead to DriveBy events.

-- ThePrisoner - 05 Aug 2003

Let me expand on the history behind this.

I think there are times when the members of a discussion deserve to know when people are popping in and listening to them. I have this belief this due to some events which happened back in the days of connect (the original connect, on MTS). I won't list the events here, but it did turn out to be useful to notice that one person was bouncing in-and-out of discussions. I can't say that I've really needed this much since that event, but it was significant at the time.

Another issue comes up from legal experiences at the University of Michigan. In that environment, one student sued another person for saying a "nasty joke" in a discussion that the person sued had considered to be reasonably private. Among the group of friends in that discussion, the joke was just someone blowing off some steam. Taken out of context, the same joke seemed mighty damning. So, first you have the problems that can be caused by the public log, and second you have the spectre of being served subpoena's to cough-up logs of discussions. Note that this joke was in what lily would call a private discussion. It was permitted to specific people, but the lawsuit and subpoena made that information public.

Note this particular issue is the significant difference between people who just happen to %log a discussion on their own, and any log kept by the server. A %log'ed discussion could easily have been made up by the user, so it would not be relevant in any legal proceedings. Any log kept by the server would be "an official record".

That does not mean that we should never allow any logging mechanism, it just means that I do not want discussions logged by default, and I do want it so members (and potential members) of a discussion can tell if the discussion is being logged -- even if they show up months after the decision was made to log the discussion.

To me this implies that any such logging, particularly publicly-available logs, should have some hooks into the server. It would be nice if the server itself would do it (thus making the process much more reliable), but we probably have to make some moo-level changes to do that. At the very least, I would like to see '/what ' indicate if that specific discussion is being logged (and where to find the log, probably), and that a multi-discussion '/what' (one that's a list instead of a single discussion) would show an 'L' in the flags field.

There is also the question of how '/review clear' should effect the logged information -- if at all. One could consider the /review buffer as "a different thing" than the logged information, or one could consider '/review clear' as an explicit request to "remove the last bits of information".

-- GaranceDrosehn - 06 Aug 2003

One other thing to consider, if you're logging discussions, is that you have to protect against "denial of service" games. Say, someone jumps into a discussion and then pastes a lot of crap into it, just to fill up disks, or annoy the members of the discussion, or whatever. This is much less of an issue now than it used to be (when disks were much smaller), but it is something else to think about. The nice thing about the current review-buffer mechanism is that you know that you'll never have to hold more than <x> events per discussion.

-- GaranceDrosehn - 06 Aug 2003

Doesn't lily still have measures in place to prevent what we used to naively call "spamming"? (I suppose now you'd call it crapflooding or DOS.)

As a point of information, as one of the more obsessive loggers, my current crop of Lily logs (dating back to whenever the first version of qtlily was usable, maybe 7-8 months) is 607MB. Disk space DOS is not something I'm worried about with lily logs, though I'm sure others may feel differently. I use lily logs, as with irc logs, email folders and IM logs, as a crutch against my exceptionally poor memory for conversations and as a local, greppable technical resource. I mention this only because I get the sense (for the first time in 15+ years) that a minority of us log and the rest of you may think we have some kind of ulterior motive.

On the legal issue, wouldn't the fact that logging is currently being implemented by a client-side bot (LumberjackClaRiSSa^?) absolve a lily server's admins from some of the responsibility and/or taint the logs in such a way as to make them inadmissible?

-- RobKudla - 06 Aug 2003

The reason I implemented review this way was to ensure that a person could not quietly skim the events in a discussion without the participants in the discussion being aware. We can all just thank our lucky stars that rhsyomme (Clover) never provided for review because skimming was an intended feature for conversation reviews. The extremely complex Clover permissions structure was intending to provide a "review without join" flag which could be attached to a user-convo pair.

Thus the design of the lily review permissions system was in reaction to that possible behavior in its predecessor.

-- ChristianRatliff - 06 Aug 2003
to top