Wedge

Tonight's a special night to me. I installed another copy of Wedge on the server, and I finally ran TE's import tool on Wedge.org. I just... wanted to see if it would work. And it does!

It's not perfect, has bugs here and there, doesn't import attachments and avatars yet, but you have absolutely no idea how wonderful it was for me to find myself face to face with a fully converted SMF forum running Wedge. The dream has finally come true!

Details

Details

And it looks gorgeous. There's no better way to test a design than to insert real data into it. I'm really happy with it now. I wasn't sure -- now I am. Party on! (Oh, and we're trying new Wedge logos, if you didn't notice. It's not final yet, but you can follow the process in the Logo Madness topic. Everything's public. Because that's how we do things at Wedge.)

37 replies

A short but sweet one.
This was something I'd been eager to do. Now it's there. The changelog is public at last, and you can follow our new bu progress in real time.
For more details, please read the first post in the topic!

http://wedge.org/pub/feats/6108/new-revs/

1 reply

While I'm still trying to figure out how to incorporate all the feedback from the package manager changes(!), I thought I'd talk about what I want to do with the ban system. Sorry in advance, this is going to be a bit of a novel: it's a big change, it's probably at least as controversial, and something about it is necessary anyway, so let's dive in.

The ban system as implemented is functional, as in it works but it's not overly elegant, it doesn't support IPv6 and I take the view that it doesn't solve the problem at hand, not one bit.

Let me deal with the IPv6 problem first, before I tackle the other stuff. The current system works on IPv4 addresses, which are x.y.z.a addresses, and whatever you put a ban (on IP address) on, it resolves to a range internally for each of the blocks. So a ban on 1.2.*.* becomes a ban internally on 1.2.0-255.0-255. Structurally, that makes sense, but IPv6 is much larger - instead of 4 blocks in the range of 0-255, you have 16 to contend with, though they're not written in decimal, nor written in the same way, but written as aaaa:bbbb:cccc:dddd:eeee:ffff:0000:1111 and similar.

There is one thing to consider, that addresses are divided in half in IPv6, the first half is for a 'network' and the second half for machines in that network, and it sounds that on the surface you could get away with just barring based on the first half only. Whether that will be successful or practical remains to be seen, but something tells me it's not that practical. It's not even that practical from a technical standpoint because if you're keeping that approach, you're not just comparing 4 values against ranges, but doing it for at least 8 - and you need to handle the high/low values, which is what SMF's and Wedge's system does right now.

I didn't implement IPv6 in Wedge in a way that would make this particular easy to implement for, because I took the view that it was the wrong way to be going about it, that any minor change extending the current direction of implementation to fit either 2x or 4x larger scope was an unnecessary performance headache, as well as a logistical one.

So, I sat back and thought about what I'd really like to be able to use in the ban system, and that lead me to my normal approach of trying to figure out what it is the ban system should be needed for, and what it should be able to do.


What is the ban system for? Primarily it's for getting rid of miscreants, and troublemakers. It isn't really a spam-solving solution, and it's not really for keeping users out that you're not interested in - it's for keeping users out that you don't want, which isn't the same thing.

Now before you start, I'm well aware that users do currently use it for keeping users out that they're not interested in, but on a variety of levels, I'm just not sure how viable that is, but we'll get on that in a minute.

So, dealing with troublemakers. The ban system lets you ban a user by name, email, IP or hostname. So you ban them, they come back under a new name through a proxy. Doesn't solve the problem much. For dealing with trolls and so on, there are better ways of dealing with them instead of slamming the door in their face - the tools used by Annoy User for example, to lock off certain features, plus the warning system that allows you to control whether they can post or whether their posts are moderated.

Of course, none of those things will solve the proxy problem, but the ban system wouldn't anyway. No, the solution is to gently turn up the heat so they don't realise that they're being pushed out, or at least discouraged from posting for whatever reason, and without it being obvious - so that they go and do something somewhere else.

If anything, the face-slam of the door is probably worse, not better, at making them go away - because what happens is that they don't have closure, they're not leaving of (kind of!) their own will, so you get all kinds of hassle as a result.


As for banning on email address, what is the hope of that? If you have miscreants who have their own domain, they can create as many emails as they like, so you just restrict the entire domain - it won't prevent them re-registering, though. So you get the extra account, you ban the entire domain, they try to register a third time and they still register - but this time they're banned and will take the hint. The problem is you've still got more accounts than you wanted in the first place.

Instead, then, how about limiting the email addresses up front? Put in the ability to restrict emails based on domain, either whitelisting or blacklisting certain domains as necessary. I know a number of users that restrict signups from mail.ru because of spam - if the domain is blacklisted, they can't even register (which is better than banning it).

There is, interestingly, a performance consideration here - and one for the better. If you ban based on email, the ban has to be evaluated more frequently than just locking it down at registration/change email time. In fact, that's going to be true of all bans - the more bans you have, the more you have to evaluate, and it has even a per-page consequence. By removing that query, you remove the performance hit, especially on long-term sites that have many bans, most of which aren't needed any longer.


Then we have IP addresses. Hello, darkness, my old friend. Putting aside the considerations of above with IPv6 addresses, the simple fact is that IP bans are really not that effective at keeping out miscreants because of proxies. That said, if you apply any of the measures in something like Annoy User, such users will likely notice it when they log out, or if they use another computer after logging out (so you can't even really use cookies on their computer) - not to mention the fact that IP addresses are shot to bits if you use mobile devices on 3G connections and similar. It's not like you can even reliably block proxy connections here.

With all that, IP bans are basically useless, except to the most technically inept of users - and they certainly don't keep out spammers, there are better ways of doing that which don't require tracking IP addresses, which are only going to be more and more useless for tracking in future as IPv6 goes mainstream.

The only salvage then is hostname, but even that... well, it's typically disabled in a lot of cases because of sluggish performance (usually because hosted machines are behind a laggy rDNS) meaning it's not a lot of use to you, and even if it wasn't, most of the time bans are not carried out on hostnames but on IP addresses, when really, hostnames would be more useful.

The solution then, might be to be able to blacklist certain hostnames if lookups are enabled and functioning, but to use it at a deeper level than keeping the conventional bans on it (there are performance considerations too), and then you could use it only if you needed it. What I might do is integrate that into our Bad Behaviour implementation, making it look like (to the user, anyway) as if their computer has a problem rather than anything else.


That wraps it up for the problems with the ban system and how they can be mitigated, but let's go further: dealing with miscreants needn't stop at fixing the current setup.

So, user-level problems, we deal with at the user level, not some global administrative level. I'm thinking we can expand the warning system as a result. Right now users can be watched, moderated or muted. It's trivial to expand that to full-on banned, and it would be useful to expand how the tail-off works. Right now you can set how quickly the warning level drops for all users (in points per day), but making that per user would make more sense, so that users who just need a time-out can be given one, and it can be done per user, rather than something across the board.

I'm also thinking we could influence other permissions, such as losing avatar and signature if the warning is over a certain level.


Just for fun, there's another subsystem I've been thinking about, that will debut in some form. Specifically, it will allow you to add rules to certain parts of the system, e.g. things to do when a post is made - so you can check the contents of a post, and if it contains words you don't like, it gets moderated and the user can be warned automatically.


Too long, didn't read (tl:dr;) summary:
* Removing the ban system as it is
* Making post moderation more prominent, probably even enabled by default (but with performance tweaks to make it run more efficiently)
* Email blacklist/whitelist on registration/change email, instead of the old method of banning
* Add hostnames to the possible rules that will be checked in our Bad Behaviour setup, so that instead of getting a 'banned warning', it looks like problems with their computer
* Replacing user-level bans with the warning system and making it more granular rather than as coarse as it is right now
* Adding functionality from my old Annoy User mod to encourage bad users to go away
* Expanding the warning system to more gradually remove powers, than just moderated and muted

I don't think I missed anything but if I did, I'm sure you're going to let me know about it!

And please, before telling me you need the ban system as it is, really stop and think about what you use in it and why you use it, then before complaining at me for breaking what you think is an essential feature, think about if there's actually a better way of doing it, like the above. Banning is not a particularly wonderful technique as explained - it doesn't solve any problem, it solves some of the symptoms. I'm trying to solve the deeper problems. Just because something is what it is, doesn't mean you have to accept it.

Oh, one more thing I forgot.

I want to introduce a 'Banned' membergroup that users go into. Not only does it have a visual consideration but a permissions one: it would let you reduce access to boards. I don't know yet whether I want to make that an on/off thing (like banning is now, except it would turn off some boards and maybe show others) or a gradual thing (as you get more warnings, you slowly see fewer and fewer boards)

But that would certainly make life interesting!

51 replies

The last few days were interesting, to say the least.

I don't exactly know what's going on in the irony department up there, but it feels like someone's determined to make me waste my time. Apart from the usual real-life issues (including but not exclusively, my driving license, of which you can see a picture on my Facebook page because, yes, I'm that shallow), and from the PC apocalypse I told you about in my last post, I also faced two new problems this week-end.

First of all -- the new computer I bought has the Intel P67 bug with the SATA interface. Meaning half of my SATA ports are not usable. One of them was being used by a hard drive so I just moved it to a safe port, but it now means all 4 of my safe ports are taken (plus my only eSata port), and I can't add any other hard drive. Thankfully I didn't exactly plan to do that either, as I already have USB3 ports which will come in handy in the future.

The only question then, is whether or not I should bring back my computer to the shop. I mean they're not supposed to sell me a buggy motherboard when Intel recognized the bug and everyone recalled their motherboards months ago already. I'm definitely unlucky these days.

Also in the let's have fun category, my ISP apparently decided to go play with my Interwebs cables, and overnight my download rate went from about 4 Mbps to under 10 Kbps. Yes, I'm talking about bits per seconds, not bytes. See, I've been on the Internet since March 1996, at which time I had a trusted 28.8 Kbps US Robotics modem. Anyone remember these? They were the top modem makers at the time. But they still ran at 3 kilobytes a second. It wasn't funny. Well, my bandwidth was one third of that for nearly 48 hours. Back in '96, web pages were just a few kilobytes of HTML, possibly a few images, later a CSS file or two, but jQuery couldn't have even existed at the time. Even the first versions, which were very light and quick to load, would take many seconds to load on an old modem. This is one of the reason why I spent so much time working on reducing the footprint of both jQuery and general JavaScript code in Wedge, when I could just have stopped worrying and dropped the compressor. I was adamant that Wedge SHOULD be faster than SMF in every possible way, and most of the work had to be done on the final output. It took me weeks just to get to the point where, comparing stock copies of Wedge and SMF, I concluded that Wedge felt faster to load than SMF. It's a personal feeling, see, it can hardly be calculated with a stopwatch. But even reaching that point was hopeless to begin with, because we'd decided on including jQuery. So we got the best of both worlds. But I still have to fight myself to determine what version of jQuery we'll ship with in the end. I mean, we started Wedge with 1.4.4, then switched to 1.5.2 with absolutely no benefit to us, and then to 1.6 where I reported a handful of annoying bugs, and once again I don't see any benefits... I guess I'm waiting for 1.7 to determine whether it's worth upgrading. But right now, as it is, I'm actually tempted to go back to 1.4.4, and save the extra 5-6 KB that 1.6.1 uses. 5 to 6 KB may not be much to you, but it's worth a lot to others.

And somehow, after my horrible Sunday experience, I can't help but wonder: won't somebody please think of the analog modems? These days, it's all about working from home and avoid commuting. So, people can go live anywhere they want. What happens to those who happen to find a heavenly place with no DSL lines around? What happens when all of the web is optimized for broadband? Will analog users end up as the digital man's stoneman? Be viewed as disabled, maybe? WAI-ARIA to the rescue, or no future for losers?

We need to stop wasting resources. Just because a font looks cool doesn't mean you should force your user's browser to download it every time they come to your website. Interestingly, that's exactly what I did a few weeks ago. I went for PT Sans as the default header-type font in Wedge, but decided against specifically calling it from Google Fonts, as fast as the service is. I just don't see the point in doing that when you can simply tell your users to download the font and install them by themselves. Then they no longer have to download it again -- and the font can start popping up everywhere.

Install a font and save a tree!
Find your raison d'être!
To arms, my brothers!

22 replies