Re: Hashcash for Blogs

Hi Jonathan,

I just read this post by James Moore:
http://www.freelists.org/archives/hashcash/03-2004/msg00003.html

It seems he had an implementation in JavaScript that was quite slow. So
maybe for web-form comments (as opposed to track-backs) the best mechanism
would be what Atom Smasher suggestion in the form of a dynamically generated
image which is hard for a machine to parse. Does anyone know of how easily
those are compromised? I'd prefer not to have to have people download a Java
applet to make this work, and most browsers definitely won't let an
externally loaded page query a HTTP server on localhost - that would be a
security violation.

OK, so the way it is panning out is this:

	1. Web-form posted comments are filtered using a image verification
system.
	2. Track-back comments are posted using hashcash. The server can
choose to produce the stamps for the posting client (especially if it is via
the web-based admin interface), or the client can provide a set of stamps
that match the referenced URLs.







Mitch Denny
w: http://notgartner.com
e: [email protected]
m: +61 (414) 610-141






 
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Jonathan Morton
Sent: Sunday, 29 August 2004 11:37 PM
To: [email protected]
Subject: [hashcash] Re: Hashcash for Blogs

> When I reply to a blog
> post I will usually do so by creating a post of my own on my blog, 
> using a client-side tool like BlogJet. When I type in a URL BlogJet 
> could poll the site and produce a stamp in the background, I imagine 
> other aggregators/posters could do the same thing. That doesn't help 
> the casual blog reader though.

It would be quite easy to include libfastmint in such a tool, if not
hashcash itself.

> Some of the neat things that I have seen with JavaScript include 
> popping a little floating window over the top of the screen with a 
> small and simple animation obscuring the calculations going on behind 
> the scenes. I would imagine that something similar could be done.

There's a big difference between Java and JavaScript.  You're probably
thinking of the former.  Java is noticeably slower than native code, but you
can indeed do funky things with it, and (very) careful coding can give you
reasonable performance.  JavaScript is slower still and much more limited -
it's part of the browser, not an independent environment.

As for threading, the point of using it is that you can do more than one
thing at once.  It's unlikely to make things go faster on a typical machine.
In the context of hashcash, it means you can have the user type his message,
and provide an interesting-looking status display, while the hashcash is
being generated in the background.

Something that may be worthwhile is packaging a JNI version of a Java class
plus libfastmint, then having it certified and hosting the result somewhere
public.  That would let Web-hashcash implementations achieve similar
performance to native versions.  A certified Java class is able to bypass
some of the sandbox restrictions that browser applets are normally subject
to.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     [email protected]
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.