GnuPG for spamfighting?
I've been thinking lately how PGP/GnuPG could be used as a spam-prevention mechanism. I'm impressed with how easy Enigmail makes signing and checking signatures -- it seems like it should be usable by non-geeks.
If GPG-signing were to be used as a spamfighting tool, the meaning of "trust" (which always seemed vague to me anyway) would have to be changed. You would "trust" someone, even if you didn't know them personally, as long as it seems reasonable that person isn't going to send spam. If you receive signed spam that is somewhere in your web of trust, you mark the signers of that key as untrustworthy.
The lower threshold of "trust" would make more sense to a lot of non-technical users -- which is important, because everything I've read about signing keys on the net, is like don't mess around, this is serious business, only sign keys of people you've really met in person and that just means that, outside a small geek community, no one signs any keys.
I trust person X not to spam me ... hell, I'd sign a lot of keys of people from mailing lists and such that I'd probably never meet IRL. And that web of trust seems like it would actually be useful -- signing the keys of "real people" would be a matter of course, and if it were simple enough and gained critical mass, everyone would want to jump onboard.
AlterniRATE
It looks like only one person has downloaded my alternative iRATE implementation. That's too bad, but I guess it is rather specialized -- limited to people who are
- on a platform where xmms runs
- are comfortable installing perl modules from CPAN
- run the official iRATE client (still necessary to download tunes), and
- are not entirely satisfied with the official client, or at least curious to try an alternative.
Looks like that's just me.
I wanted to get my track-selection algorithm into the official client, of course, but it was a substantial change which would have been hard for me to write in an unfamiliar language. Combine that with a lukewarm reception for my proposal that made it seem like a patch would have a hard time getting accepted anyway, and I decided it was better to write something for myself in a language I was much more comfortable with.
I'm continuing to develop it and put the latest out on my website, but I'm not bothering with any official announcements.
Hanzi Quiz
I haven't touched this code in ages, but I have an idea how to improve it which I want to implement soon.
I wrote a utility program in perl (which you can find in the hanziquiz tarball) which takes pinyin with tone numbers (e.g. ni3 hao3) and converts it to pinyin with tone marks using utf-8 characters (something like nĭ hăo -- although that's with unicode numeric entities instead of raw utf-8). Now I'm thinking, if I move that conversion into the javascript of Hanzi Quiz itself, I can
- make it easier to edit the test entries
- have a fallback for browsers which can't display the accented characters (determined by a can you see this? up front)
Sounds pretty good, eh? The problem is the pinyin character ü (coded as a named entity here). That's hard to enter in text editors (except perhaps
as an html entity ... oh that's hard too, just not impossible). In my perl conversion tool I use the character 'v', which isn't used in pinyin, to represent ü. I understand that's common, but perhaps not as common as 'u:' or 'uu'.
Should I code to expect the input to use 'v' (which is reasonable if I'm the one entering data), or should I try to handle other representations? What if I encounter html entities, or non-ASCII utf-8?
Eh, best start coding for the simplest ('v') case, and work from there. Yeah, I've talked myself into it just now.
LiveJournal
I have a personal blog over at LJ. I had hoped to keep a blog on my own site, but I eventually decided that LJ was all set up for me, so why not just blog there?
The entries are few and far between now, but will probably become more frequent in the future.