December 22, 2004

Approving user accounts through a network of trust

It would be very nice to handle identity approval on a more networked level. Basically I would trust authors of my entire blogroll to approve users with a degree of wisdom I could live with for my own site. I'd probably also trust their blogroll, and so on. Of course this network of trust is in no way explicitely mapped, so I have to treat all new users alike. Meaning of course I'm going to assume the worst.

A few formats exist that allow to express trust in a machine readable way. There are a couple of trust related extensions for FOAF, but FOAF is RDF and no one gets RDF, which makes it a poor choice for a format that is useless unless widely employed.

Earlier this year I had a conversation with Tantek Çelik about abusing the fabulous XHTML Friends Network as a way to express trust. Unfortunately the idea never got anywhere, which is something of a pity.

I think that given the unequal distribution of weblog audience it would be very feasible to escape the chicken/egg problem of metadata for this purpose (meaning no one likes to annotate data unless everyone else is already doing it). If only a few A-List bloggers would step forward and publish a few thousand combined trust ratings in a format as simple as XFN, this thing could really take off.

This whole issue about approving people and assholes posting viagra ads is so old, I cannot believe we haven't solved it already. I realize that trust can be delicate thing to universally define, but we don't need a perfect solution but a solution that is better than nothing. With some effort we could take away 90% of the pain that is abusive behaviour on anything that has a "Post" button. Let's not keep that chance unused forever.

December 21, 2004

A nicer way to handle account approvals

Aristotle proposes a more user-friendly modus operandi for sites that require new user accounts to be approved by a moderator:

(...) let users write posts before their account is approved. (...) Their messages won't show up as long as the account is marked as unapproved, however. As soon as an account gets approved, all the previous and any future messages posted using that account show up immediately. This way, new users can butt into a discussion as quickly as possible while spammers remain locked out.

Something like this would already work in Movable Type if anyone would care to sign up for Six Apart's Typekey service, which is not the case.

I think Aristotle's idea would be particularely effective on discussion forums, where posters tend to stick around for a while. His idea wouldn't make such a difference for weblogs, where you have a large percentage of hit-and-run contributions by commenters with no plans to ever return. But more on that in my next entry.

The best spam prevention technique is the one you don't blog about

Assuming I had discovered a somewhat effective comment spam prevention technique, I am not entirely sure why it would be a good idea write about it in public. Granted, sharing your newfound approach is a noble act but it will also be rendered useless by the time it reaches the mildest degree of popularity.

Comment spam is a fight the weblog community is not ever going to win. It's funny how we laugh at the industry's quaint attempts to devise of a copy protection mechanism that outlasts the next weekend and at the same time expect to solve comment spam in the same fashion. You cannot have low-barrier access and be in full control, too. Evading comment spam is all about making spammers find an easier target.

Comments (3)

December 13, 2004

Mapping weblog conversations through semantic markup

James Tauber proposes the use of more semantic markup to allow the meaningful mapping of conversations spanning multiple weblogs:

what if citation indices were annotated with the relationship between the newer publication and what it was citing? You could have relationships like "quotes", "summarises", "provides further evidence for", "argues against", "answers question posed by", and so on. (...) People could link to this entry with annotations like "agree", "agree with additional ideas", "agree with caveats", "seen something like this already", "really dumb idea with reasons stated". (...) Kind of an XFN for memes.

One can only wonder why XHTML Meta Data Profiles, the fantastic plan behind XFN, hasn't spawned more ideas like that. When I first encountered XMDP I was just smitten by the simplicity and unintrusiveness with which XMDP allowed to spray bits of semantic pixie dust wherever you need it. I don't think any other piece of web technology ever felt so right at first sight.

Yet wide adoption of XMDP-based markup failed to appear. Web community, what is wrong with you?

Update: The earlier "Tracking weblog conversations" entry you used to find here managed to completely miss the point of Tauber's proposal. Thanks Yoz for helping me with what should have been obvious.

December 08, 2004

Zero treatment

Last year I released a fixed-width font for programmers called Triskweline. The feedback I received on Triskweline so far has been very positive, except for the few who keep insisting that Triskweline miserably fails the idiocy test for programmer fonts because it doesn't slash zeroes.

You know, like mixing up zeroes and the capital "O" character would be an issue that ever occurs in your daily programming routine. I have to think very hard to even come up with a word that features a capital "O" in code. Obviously, words beginning with an "O" are out of the equation as most languages don't allow you to begin a word with a numeric character.

Alright, I remember one: CardStateObserver. I immediately see how one could mistakingly write CardState0bserver instead. Happens all the time.

Maybe I simply see Triskweline as a way to discriminate against all the people who had been practicing the art of l33t-speech at some point in their lives. Which I think of as a noble intent.

Comments (1)

December 06, 2004

Open classes are the stepchildren of langage design

For a construct that can single-handedly change the way you think about programming, open classes seem a lot like collateral damage in a language design accident.

Open classes allow you to add or rewrite methods from another namespace than the one you currently write in. Should you be dissatisfied with the way a Ruby Array prints out on the screen, just go ahead and redefine String.to_s. while screwing with core classes might not make for wise examples, there are countless opportunities where open classes can save your ass.

Whenever you work with classes that don't respect Inversion of Control and fetch their dependencies on their own, being able to reopen the victimized class and add that additional bit of needed functionality is a godsent.

Unfortunately, when you don't want to rewrite, but merely extend an existing method you quickly find yourself being out of options, as there is no way to refer to the piece of code you are about to replace. There is no way to call the method-implementation of a super-class because there is no super-class. You can either rewrite a method as a whole or not at all.

Now if we open classes hadn't been denied that final ounce of love, we'd have a poor man's flavour of AOP built into every scripting language worth mentioning at this very moment.

That would have rocked.

Update: Ruby lets you alias the method you'd like to overwrite, overwrite it, and then still call the old method using the alias. Neat.

Comments (2)