by Rohit Khare; see also Publications
New kind of information space, the Personal Web.
Two player economic model: user (god) spends attention on “stuff”; robot fetches and organizes stuff to maximize user-wealth within constraints on storage, bandwidth, and archiving requirements (such as ‘keep everything directly to or from me’).
The robot can find other bots to trade with. The robot can only make promises of effort it will undertake in the future, so an additional constraint on “good” players is that they not over-commit – but the problem is determining the credibility of those outsiders to begin with. In other words, everyone is born with a worthless currency, but might be willing to extend credit denominated in it.
So what is there to trade? The system is initially quiescent. The first change is that someone’s user says something. That utterance is a now a bargaining chip that the robot can use – modulo the costs of transporting it (mainly opportunity costs of abandoned latency; in theory, you can always buy more bandwidth).
The immediately consequent question is, how does the “buyer” robot know how much to pay for this new item? We could turn this system on its head and say that the only form of progress is for buyers to make offers first, and that merely sending bits is anti-social and risks shutting off your credit.
Suppose the basic HELO message is “my name is robot-# and I’m interested in <matcher>s” where <matcher> is a list of URLs, or public-keys (to check signatures), or a regular-expression, or a prefix of a hash of a URL or a bloom-filter, or…? Well, that’s not quite enough, I’d like to give a sense of the relative value of those predicates, so it might be a matcher-price vector (btw, is an item that matches multiple predicates worth the sum? The max?).
But since time is the enemy – latency being the variable to minimize while maximizing user-wealth – there’s a countervailing impulse to keep it short and snappy; you might want to guess what parts of your “order book” are most worth revealing to that other robot. Similarly, we’d probably need a built-in mechanism for deferred transmission: “I’ll accept any item up to 1K, but longer than that please substitute a URL where I can go fetch the content myself once I decide to.” But then again, that can be safely ignored for now as a ‘mere matter of representation’ – there are lower-level protocols to rely on to ration bandwidth amongst competing concurrent item downloads.
So the price is denominated in a pairwise currency that, I believe, has a lifespan longer than a TCP session (thus, the robots need longer-lived identities. That pairwise currency “XY-bucks” represents some unit of effort Y will expend on behalf of X in some distant future (YX-bucks being the reverse). This means that for robot-X to make a wise decision about where to invest, it will need very sophisticated models of the “inflation rate” of these other currencies; the level to which there may or may not be inter-market learning about the reliability of XY-bucks based on rumors of the value of XZ-bucks and ZY-bucks; and more basic risk-management principles limiting how much XY-bucks X trusts to leave ‘on deposit’ in the ledger of the Central Bank of Y.
So here’s the game:
Robot X serves a god, user U.
Robot X is endowed with a finite amount of storage, a finite bandwidth to the internet, and faces a vector of constraints of the form <other-robot-ip-address, max-bandwidth, avg-latency>.
User U gives Robot X a vector of <matcher, utility> orders that indicate U's current demand for information.
Robot X can connect to any other Robot Y and announce a (portion of the) demand vector of <matcher, XY-utility> that indicate X's current demand.
Robot X can send any item of information to Robot Y; if and only if that item passes a matcher test previously announced by Y, it can assume it gained
YX-bucks of utility as previously offered (and, yes, there needs to be a periodic announcement of balances to prevent misunderstandings accumulating - and, in fact, someday the Central Bank of Y may be well-served to publish a complete accounting of all of its balances to all of its peers to show that it is not inflating away the currency to worthlessness - because while there are notionally separate YX and YZ currencies, it seems that the money supply of Y is highly correlated in those markets - it's limited by Y's users' utility at best.)
And that's about it - though there are surely wrinkles around the edges like how X can "disconnect" from Y (or, more effectively, firewall its packets out from consideration entirely); or how Y can warn X of what languages it will accept <matchers> in; and so on.
So to reduce this problem into more practicable form, assume that all bandwidth limits are expressed as bin sizes per unit time (say, 1 second). Also, for now let's assume that the time it takes to evaluate a <matcher> on an <item> is negligible - though that could later be allocated agorically too.
For each timeslice {
Make_most_profitable_move()
}
which could be refined into:
While (clock-is-ticking) {
// constraints:
update_total_bandwidth ();
update_pairwise_bandwidth ();
update_pairwise_exchange_rate_estimates ();
update_user_demand_curve();
foreach (trader T) {
response_basket = pick_items_from_inventory_with_max_price (T's_demand_curve, T's_max_bandwidth);
request_basket = pick_items_from_demand_curve_with_max_price (U's_demand_curve, T's_max_bandwidth);
//decision: do I want to stack up more XT-bucks or spend them?
If (Receivables[T] - price_of(request_basket)) >
(Payables[T] - price_of(response_basket)*exchange_rate_estimates[T])
then proposed_action = response_basket;
else proposed_action = request_basket;
}
execute(solve_bin_packing_problem(all_proposed_actions, total_bandwidth))
}