I don't understand why any sort of concept of karma is necessary if people just use Bitcoins for it. Pay Bitcoins if you need space, receive Bitcoins if you rent it out.
Don't get confused by the variable-names or metric-labels:
"Pay bitcoins if you need [RESOURCE_OR_SERVICE], receive bitcoins if you rent it out."
If what you need is, purely and solely, storage space, have you compared the monthly cost per terrabyte of writeable DVDs plus the oneshot upfront cost of installing enough DVD drives to put that much DVD space online all at once at your own location?
If what you need is, purely and simply, offsiteness of space, have you compared the monthly cost per terrabyte of sneakernetting or snail;mailing the DVDs to an offsite location?
If what you need is purely and simply, transport from onsite to offsite, again compare DVD-by-sneakernet.
If what you need is, purely and simply transport from offsite to onsite, again have you compared price of DVD-media transport?
It continues to sound though as if you are actually trying to palm of or fob off some dynamic combination of probably at least three of these pure and simply commodities onto a one-dimensional metric (known as bitcoin) that already carries the burden of also having to be equal to dynamic quantities of an endless number of other pure and simple things and complicatedly dynamic things and indeed any thing or service whatsoever.
If you really want to take it down to how many bits you receive from offsite, how many bits you send offsite, how many copies of each bit reside on each reliability of peer storage reachable at each possible bits per second rate at what percentage chance on any given second, minute, hour, day, week month or year, that is vastly complicated set of markets, where you or your agent needs to determine how many bits per second seconds how many bitmonths of how likely to be accessible when you need it storage is equal in value to you to how much more or less of any of those factors. How much do you value the snappiness of response, as measured in number of bitmonths stored? Does it differ according to how many bitcoins the material requested has been stored? And on and on and on. Is two bytes of storage worth more or less to you than two bytes per timespan for two timespans of transport? Is outgoing transport worth more or less to you than incoming trasport? Etc etc endlessly.
Once all these factors as to your personal preferences as to when you want how many more bits per second rather than how many bitmonths of remote storage in use and so on and so on have been all reduced down to a single scalar numeric value, then how many satoshis or bitcoins are you willing to pay per how large a value of that scalar metric can be tested by offering you such a scalar on a market.
If however you insist that the scalar itself be labelled bitcoins, then it is reduced to a market in which the commodity being auctioned off is known as bitcoins due to your insistence that the scalar result of the reduction of the commodity to a single scalar must be bitcoins rather than being number of bits of data you have on offsite DVDs available by sneakernet using couriers, or speed of vehicle said couriers will use up to and including putting the DVD into a transporter so it materialises on your desk or directly changes the magenetism of your hard-drive.
It is too vast a field of not-the-same-thing that you are trying to boil down into one thing. Having boiled it down to one thing, whatever one thing you boil it down to so as to have a BTC<->ThatThing market, if you insist that thing ITSELF must ITSELF be known as bitcoins rather than being known as "general scalar metric of offsite-storage-network resource consumption quota" you will just end up with a totally confusing market, a "BTC meaning the digital currency"<->"Bitcoins meaning the metric of usage of network storage resources subsuming upload volume, download volume, storage volume and duration, bits per second sustained of download, bits per second burst of download, bits per second sustained of upload, bits per second burst of upload, and other ancillary factors".
It seems simpler and clearer to use some word other than "BTC" or "Bitcoin" or "Bitcoins" for that second metric, the commodity metric being offered for sale not AS bitcoins but IN RETURN FOR bitcoins.
In GNUnet, if I recall correctly, that commodity-provided-by-this-system metric is stored in a variable some coder or other happened to name "karma".
It is simply a human-and-compiler-readable label meaning "that scalar value which serves as the numeric metric of the commodity provided by this network/application".
Hindu or any other mysticism might only be some strange random reference that coder happened to find useful at coding time as a mnemnonic by which to refer to that variable/metric.
So for your purposes maybe it would suffice to use a preprocessor macro to change the name of that variable to QUANTITY_OF_SERVICE_DESIRED_BY_USER so that you will be able, upon reading the code, to make the mental leap to the aha moment that, in such a network, THAT is the variable you would be best served by spending your bitcoins to buy an increase in numeric value of the bits that variable refers to as interpreted as representing a number.
Or, you could chose to change its name to AMOUNT_OF_STORAGE_DESIRED everywhere instead, while people also interested in how much speed it amounts to rather than how many years bits offsite will survive if they don't request them for years could use some other label for it.
It is a complicated service involving redundancy and latency and bandwidth and on and on and on. Marketers would love to game you by offering a different product, different in any of the details that go into the whole generic concept of getting your bits offsite and being able to get them back onsite, whether by dialup or sneakernet or wireless or TCP or UDP or whatever, so they can claim to be a different product entirely, maybe not even a commodity (generic) product even maybe but rather a prestige boutique product incomparable to commodity offerings so they belong on a different market entirely and should not be compared to commodity offerings, especially not on price, since afterall their vast marketing budgets and ridiculously ignorant user-bases' need for hand-holding's accomodation by vast helpdesk centres precludes any comparison to any raw commodity.
To be a commodity that can be assigned a scalar value in bitcoins, a thing has to be gotten down as close to a scalar value as possible first in order to have a single value, usually labelled quantity (as in X number of porkbellies, X number of grams of gold, X number of remote storage bitspeedmonthdirections or whatever), so that a market can be a "quantity of money" <-> "quantity of that very very specific commodity" market.
Notice even the grams of gold might be this that or the other fine-ness of gold, so even there there are more variables that in casual chat one takes for granted but that in fact a .999-fine grams of gold market is distinct from a .333-fine grams of gold market and so on.
To commoditise a thing you need to get it condensed down to the point where a market offering a scalar value of it per scalar value of a currency makes sense to the participants.
Already in Open Transactions we are seeing how fragmentation of markets scares off potential customers, with some potential customers thinking that having separate markets for ones of bitcoins, tens of bitcoins, hundreds of bitcoins (or s/bitcoins/porkbellies/ or s/bitcoins/shiploads of porkbellies/ or s/bitcoins/grams of porkfat/ or whatever, an assset is an asset is an asset, all are tradeable each against each) is in some way bad or awkward or "too complicated" or something even though in business it is actually very often the case that the price of grams of something, per gram, differs from the price of tons of that same thing, per gram.
So dont keep getting hung up on the name of the variable that serves in the code as the measure / metric of what it is that is being provided, instead consider whether that which is provided suits your needs and whether you wish to be provided with more of it or less of it than you are currently being provided. If you want more of "the service", get that number increased, whether by paying bitcoins to have it increased or by whatever other means. It is the measure aka metric of the service provided by that software.
-MarkM-
