Applications that make money

Posted 29 Oct 2001 at 17:26 UTC by niksilver Share This

We've just launched Jtrix under the LGPL and are looking for input from Advogato people. Jtrix allows you to write apps that grow and shrink and move around to find the best places to live, and so never cost more to run than necessary. Is this of value to you?

There's a brief intro doc, the latest downloads and more papers on the home page. But in brief:

  • Jtrix applications can find their own hosting and services, and everything is accounted, so they never use more than they need and can always be billed precisely. No more spending hundreds of thousands of dollars on a redundant server farm three months before you hope it will be needed.
  • A good example would be the problems of SourceForge, mentioned recently on these pages. If we had this in Jtrix then the more popular projects would be directly supported by micropayments, while the less popular ones would shrink down and not need to spend as much.
  • The success of Jtrix depends on being widely accepted which is why we released it under the LGPL.
  • We need developers from the open source community in order to prove its validity.

So what do you think of Jtrix? Do you have a need for it? Would you consider joining us as a contributor? Please let us know.

Which Java VM?, posted 30 Oct 2001 at 02:09 UTC by Qbert » (Journeyer)

I'm a little behind the times when it comes to Java; I haven't written anything in Java since late 1999. At the time, all the Java VMs for Linux sucked very badly. Kaffe was unstable and out of date relative to Sun's ever-changing suite of libraries; Japhar didn't seem to be actively maintained; Sun's VM was unstable, prohibited modification and redistribution, and was supported only as a buggy port maintained by Blackdown (which free service Sun nearly lost when it presented the Blackdown port as if it were its own work, even after backing down and apologizing). IBM's jikes was a very fast compiler, but without a decent VM to run its output it was useless. I gave up in disgust.

So, I'm hoping someone has solved these problems since I turned my back on Java. What do you think? What is the most stable VM for Linux? The fastest? (Is there a decent JIT for Linux yet?) The most complete in terms of tracking Sun's library APIs? If you tested your code on Linux, which VM did you use? Is there a clear choice, or are there different VMs that fulfill these criteria? Is any of these free software?

I liked Java as an object-oriented language, but I couldn't stand the implementation. I'm not likely to use any Java project till it shows good performance and stability on Linux, on a free VM.

stay away from the "micropayment" word, posted 30 Oct 2001 at 06:10 UTC by splork » (Master)

Unless you actually mean that 5 cents will translate into some fixed amount of some definable computing resource in the system, avoid at all costs the use of the term "micropayment."

People/users get very weird as soon as they're told that some number on a computer might be viewed as actual money. We had this problem with Mojo Nation in that our "micropayment" system was much better described as an internal barter system for computer resources.

M*cropayments, posted 30 Oct 2001 at 09:00 UTC by niksilver » (Journeyer)

Hi Splork, thanks for the reply. We certainly looked at MojoNation and it has some good ideas. The idea is to buy real things such as CPU, disk, etc, as well as mail accounts, database space, and any other service you can dream up. If this can be done efficiently enough then you know what you're spending your money on as you spend it.

Perhaps "micropayments" isn't a good word to use. But people who spend thousands of dollars on a Web site (and even those who spend $200/year on their own personal home page) know that resources cost money, and if they need more then they can spend more, but if they need less then they shouldn't have to pay as much. If that's called "micropayments" or just "not much money" it's still the same thing in practice. Either way, it's important that you shouldn't have to spend thousands of dollars in advance - that creates a trading gap, it means risk and/or borrowing large amounts of money and/or selling a share of your company/project to other people to hold you over until that up-front investment pays off.

M*cropayments, posted 30 Oct 2001 at 16:59 UTC by uleonhardt » (Journeyer)

IMHO, the real point of a micropayment would be to pay for a one-off interaction with an unknown party. For example, a directory lookup could conceivably be paid for by a micropayment. Then, one could create a directory service and make money buy charging for lookups. Technically, it seems quite possible to have a pervasive infrastructure enabling efficient micropayments.

Is this realistic? As the previous poster pointed out, people are not very comfortable with micropayments, at least on the Internet. On the other hand, few people seem to mind services being charged to their telephone bill. So isn't it just a question of the user's mindset? I think it is going to be a slow process, but eventually most people will learn to pay for most services on the Internet.

This may not seem like a good thing, but it would enable better/more sustainable business models than seen during the last Internet bubble.

Open source Java infrastructure, posted 30 Oct 2001 at 21:21 UTC by chalst » (Master)

Qbert: I wrote this diary entry a couple of weeks back about the big difference between the exciting, dynamic world of open source Java application development, and the relatively bad state of open source Java infrastructure.

It's much better now than in 1999, though. Blackdown's JVM is stable, if not lighting fast, and there is promising work appearing, especially the support for native code compilation of Java in gcc-3.0, and the support by HP of open source Java (I'm thinking of their big cntribution to the Mauve project). What is desperately needed is a decent open source implementation of J2EE, and what would be very helpful is an open source reimplementation of Swing. People are working towards the former, but there looks to be little chance of Sun certification, and nobody is doing serious work on the latter.

harsh reality of m*cropayments, posted 31 Oct 2001 at 07:59 UTC by splork » (Master)

uleonhardt: running a micropayment infrastructure to cover tiny transaction costs is less useful than it may seem. To use your directory lookup example, the micropayment resource overhead is much larger than the lookup itself.

Here are some issues with micropayments (and some notes on what we did in mojonation):

  1. The cost of performing an accountable transaction between two parties is much higher than most people ever assume. (hosting, cpu, redundancy, backups, security and administration of payment authorities costs a lot). If your payment system is exchangable for real money in any way, you need lawyers and financial gurus to pay attention to the loads of required work for being a financial institution. This can not be done openly, a corporation or government will need to be involved if actual finances come into play. (amusing note: The Principality Of Sealand is both)

  2. You need to determine what the smallest unit of work/resources worthy of incurring the actual overhead of a real payment transaction is.

    In mojonation we used a microcredit system, using a real payment only when the credit balance was large enough to warrant the overhead. Ours defaulted to extending credit without any prepayment to keep the overhead low on transactions between previously unknown parties. However, this is vulnerable to attack by distributing queries among redundant parties and to parties who change their identity frequently. To prevent this, one could require a prepayment with unknown parties so that instead of on credit work is performed from a prepayed tab. Then the problem changes to be that new parties may appear, take a prepayment, then disappear (including reappearing as a different party to collect more prepayments). Note that prepayment is more like a subscription system, just finer grained.

  3. Determining the microcost of a resource is difficult if not impossible.

    We chose paris metro pricing in mojonation. How much a party charges is solely determined by the offers it has received at that instant as well as its current resource usage load (cpu, bandwidth, etc). This means service will cost 0 (or some other configurable minimum to cover fixed overhead) much of the time. Parties who offered higher payments have their requests served first. Also important is that it prevents the need for any price setting/advertising/publishing/negotiating which would otherwise complicate a system by adding significant extra message and latency overhead. The advantage of using 0 as the minimum cost is that parties in the system who choose not to pay aren't screwed, they'll just get the worst class of service.

  4. How will denial of service (DOS) attacks effect the system. If the payment authority is taken offline or significantly overloaded do things still work? Do some parties gain and others lose (thus providing financial incentive for launching a DOS attack)?

    This was another reason behind the default behavior of extending credit without a prepayment in mojonation. That way everything doesn't stop when the payment authority is being nuked. Unfortunately it could be abused (and no doubt would be if mojo were exchangable for real money)

  5. Consider the impact of taking a service that is free and requiring micropayments for it. How would sourceforge support itself in your example when many of its users are not willing to pay anything and would seek other philanthropic project hosting locations or put up with less reliable but free home dsl line hosting?

Free service require m*cropayments..., posted 31 Oct 2001 at 11:00 UTC by Malx » (Journeyer)

Consider the impact of taking a service that is free and requiring micropayments for it.

What if thouse m*cropayments whould be not for service , but for additional service?
It could be turning off banner ads, or requirment for better QoS (same as with CPU)

BTW. what whould be with web-searchers crawlers? Need Google pay you for indexing your site? :)))

There is one service... Fileplanet or something like that (found link on you could make a month subscription for geting free demo versions of games, posters etc.

m*cropayments continued, posted 31 Oct 2001 at 12:07 UTC by uleonhardt » (Journeyer)

splork raised some interesting and valid concerns about the practical feasibility of micropayments. I think micropayments are a hard problem. (Or perhaps it is difficult because we try to replicate the off-line world in cyberspace, inappropriately ?) IMHO, MojoNation had a pretty sophisticated infrastructure for making small payments efficient by batching them up.

Let me respond to the points raised:

  • Interface to the real world. At the moment, we follow the approach that we have (possibly several) on-line banks that are self-financing. As soon as the on-line currency will become convertible into real money, those on-line banks will also have to become proper banks in the real world. That's the easy bit. Then we get taxation issues. By default, the government-imposed system for collecting value-added tax would have to be extended into cyberspace. That would be a real pain! Perhaps some kind of exemption could be granted. Then there is the issue of controlling the money supply within cyberspace. Presumably we there should be some inflation in order to make people spend their money. I guess with have to take one step at a time.
  • Cost of payment transaction. I think classical micropayments (one-off interaction with unknown party) are only efficient if the payee can verify the payment (to some degree) without contacting a third party. The challenge is to make cheating more expensive than paying up. However, there needs to be some fairly smart "immune-system" in the background that weeds out persistent cheats. And that's the difficult part. On the other hand, if the micropayments can be batched up (eg. a subscription-type scenario) things become easier - except that one side has to take a risk (as pointed out in the previous post). I think that can't be avoided - again this leads to the need for a trust metric.
  • Pricing resources. Our approach is top-down, ie. we calculate what it takes to run the machine, depreciation of hardware, etc. This leads to prices of basic resources (CPU, disk, memory). Services would be priced to cover the cost of the necessary resources, plus a bit on top for profit.
  • Financial incentives for DOS. Never thought about this one. Call the police, I guess.
  • Starting to charge for a previously free service. Very difficult. That's why its important to have the financial infrastructure in place from the very beginning.

m*cropayment extravaganza, posted 31 Oct 2001 at 21:09 UTC by splork » (Master)

quick note: it sounds like you're pondering inflation to prevent hoarding. That's one approach but may not be necessary. With many forms of digital currency (such as signed digital tokens), each coin can be given a life time such that it must be cleared through the central authority by a certain date or it becomes useless.

modelling the real world or not, posted 1 Nov 2001 at 02:00 UTC by jerry » (Journeyer)

IMHO virtual money (I wouldn't call it m*cropayment) can work only, if it works at technical, social, philosophical and legal level at the same time. We are definately not there yet.

Instead of a longer reply here, I decided to code one demo cent and explained the game to illustrated my view.

Re: modelling the real world or not, posted 2 Nov 2001 at 07:47 UTC by jerry » (Journeyer)

Sorry for replying to my own post. Clever me, all links needed authentication! :-( Here with fixed port number:

Instead of a longer reply here, I decided to code one demo cent and explained the game to illustrated my view.

microsoft research "millenium project", posted 3 Nov 2001 at 15:41 UTC by lkcl » (Master)

you would do well to examine the "millenium" project on basically it was a distributed OS that allowed programs and resources to move and/or duplicate up to where the demands were being made on the network.

i.e. if a site on the end of an ISDN line suddently became slashdotted, it would automagically be duplicated up to a line with a big fat pipe, for 15 minutes, until the demand went away.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page