People often ask me to explain NeuClear, and until recently, it's been quite mystifying. I don't mind that, as most newcomers find Ricardo quite mystifying as well.

It came to me just recently, that NeuClear is "like Ricardo, but with lashings of XML."

As a first approximation, that is. What all that means beyond a first approximation depends on complex personal questions such as "what do you think of XML..."

It would definitely be useful to go beyond that, as, over on the webfunds.org site, there are links to various other systems which might be of comparitive interest. Pelle, can you ... improve on this 1st approximation?

From a low level technical point of view it is very much like Ricardo with XML.

One of the reasons for the XML is that I want it to be as easy to develop for as possible. FOr example an ASP.NET or Python developer will be able to write code to create NeuClear transactions with relative ease.

I have never 100% understood how the web funds server works. I think our usage models are different (maybe I'm wrong). Have a look at some of the possibilities on this page: http://neuclear.org/display/neu/Usage+Models

There are definitely many similarities and Ricardo was definitely a major inspiration.

On XML --- XML seems to shine as a data transport layout between dramatically different entities. Such as administrative boundaries, and from one application to another.

Where it seems to be less effective is in very precise work. Also, from what I've seen of the digital signature formats, they are hard to work with. For that reason I'd still plumb for "own data layout" where precision is called for.

Still, it's probably one of these debates that goes on and on, all the while avoiding the real issues. XML is one of those things that is somewhere < 1% of the design space, but > 10% of the discussion space!

I suppose the main thing is to question whether Ricardo would be done with XML if we started today. The answer to that is "I don't know, and I'd need to be a lot more comfortable that the digsig thing worked well before committing to that...."

The link href in the original message is spelled wrong.

s/nueclear/neuclear/

Thanks... I must have fixed this four times, I don't know how it slipped back in.

Usage models - http://neuclear.org/display/neu/Usage+Models

Web Usage Model - Ricardo doesn't currently do that, we did once have something called the SOX Shop, with the 1st generations. Since then, I've steared clear of what might be the "shopping cart invoice generator" approach because I view that as very individual to each usage sector, and it's too difficult to create the tools in advance. IOW, it's an application issue, not a payments issue.

Ticket Model - oddly enough, with the WebFunds token (e.g., bearer) project, that's easy! Not quite in the way shown on the Nueclear page, but it permits two spaces, token space and ricardo space (with appropriate accounting and crypto of course) and provides means to move back and forth. Using big random numbers as ticket numbers would work there.

Web services Model - that I don't quite follow.

The above is a very high level comparison of course, and could be specious. The devil is in the details. But, I do think that WebFunds could deliver all those things, mostly because it was designed to deliver a whole range of models.

What it does do which might be different to architectures is that it separates out the payment from the trade. The notion that "someone sends a packet that asks for a packet" is considered to be a higher layer thing in Ricardo.