Bantracker redesign

[Lorenzo J. Lucchini]

On Tuesday 08 April 2008 08:03:54 Dennis Kaarsemaker wrote:
> On di, 2008-04-08 at 01:02 +0200, Lorenzo J. Lucchini wrote:
>
> > I'm not a big fan of the one-year-backlog thing.
> > Sometimes very old bans *do* become relevant again.
>
> We should have some sort of private wiki thing for discussing such bans.

Well, maybe, but what's the drawback of keeping unlimited backlog, once space 
issues are not an issue? For instance, the *complete* logs of #ubuntu from 
irclogs are about 300 Mb, compressed. If only a limited number of channels 
are tracked by the bantracker, I think the space taken could be a fraction of 
that, no?

> > Besides, I think that by using the "one minute timer" trick, stored log
> > sizes will dramatically shrink; also, Python offers string compression,
> > and I really suspect that keeping logs compressed (whether in or out of
> > the database) would have a huge positive impact on space, and a
> > negligible negative impact on performance (at least unless you're going
> > to provide searching inside the logs).
>
> String compression may help, that would just unconditionally serve the
> data compressed.

Not sure what you mean here by unconditionally serving the data compressed.

> > On a related topic, I think the bantracker should be publicly accessible
> > again, but with two important limitations for anonymous users: comments
> > should not be visible (or perhaps some specific comments could be tagged
> > as "sensitive"), and banmasks should be scrambled.
>
> Define 'scrambled'. I agree that the bantracker must be public again,
> which it will.

Well, I don't have an exceedingly easy implementation scheme in mind.

But basically, I wouldn't want the bantracker to be usable for finding out and 
studying the banmasks we use, and for instance exploit that information to 
ban evade. Of course, you could say such studies are possible even without 
the bantracker... but that doesn't mean we should make them easier.

Ideally, the bantracker would only show the *nickname* of the banned person, 
for anonymous users. Now, I understand that linking bans to nicknames is not 
particularly easy, but then, it would be a useful thing to have even 
regardless of this issue.

> Would be nice, could have a ManyToManyField for that.
>
> > A similar effect could be achieved also by having the search function
> > look at comments, too, so one would simply have to mention the relevant
> > nicknames/mask in a comment to make the action show up in a related
> > search.
>
> As you said before, that negates the compression. Which do you think is
> more important?

Well, but I was mentioning compression for *logs*, not comments. Comments 
would tend to be pretty short, anyway, so why compress (especially, 
compressing each comment separately would probably yield a ridiculous 
compression ratio, while for logs that would work well).


by LjL
ljl at ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/ubuntu-irc/attachments/20080408/b0e89b0e/attachment.pgp>