The purpose of this document is to help hackers start writing more sophisticated business logic for their MojoNation brokers. Writing better business logic for your beta MojoNation broker is sort of like a fun contest, and the reward for winning is making more beta Mojo and getting better file service. This document is doomed to be incomplete and flawed, but it will hopefully be better than nothing. This is a living document, so please ask questions, suggest changes, post patches, etc. The most up-to-date version of this file can always be found in CVS on SourceForge, and is browse-able over the web via this link. (You have click on the latest version number to get the document.)

The whole business logic concept

Mojo Nation software comes with several business logic rules built in. There is a good chance you will want to tweak them. This is because you, the Mojo Nation user community, know your operations much better than we do. In the meantime, we have made it easy for you to create your own business logic, which you are encouraged to not only write but distribute to others.

How it works

Most business decisions are made on a per-request basis, by selecting among potential service providers. Each service provider is rated by adding "handicaps" (for high prices, unreliability, unfamiliarity, high latency, or other factors), and going with the one which comes out lowest. To add business logic, create your own handicapper and register it.

Writing your own handicapper

If you learn from examples, see pricelib.PriceHandicapper and UnreliableHandicapper which make your broker tend to prefer cheaper and more reliable counterparties, respectively.

If you learn from specifications, see MojoHandicapper which describes the interface to handicappers, and suggests some examples.

Handicappers get registered with a broker in MojoTransaction, (search for "andicap" to find the relevant section of code). After you've written your new handicapper, add a call to register it there.

Here are the comments from MojoTransaction.py:

A handicap function must take the parameters counterparty_id, message_type, and message_body and return a numerical value, DISQUALIFIED or a dict containing: 'multiplier': a float to multiply the inprogress handicap computation by 'additive': a float to add to the handicap (same as returning a float)

Sum of squares addition is used: All additives are squared before being used.

Numerical values will be added to produce a total handicap. Multipliers will be applied after all additions have taken place. DISQUALIFIED will completely disqualify the given counterparty.

Examples of handicappers are one which returns the advertised price, one which returns the cost of the relay server, and one which returns DISQUALIFIED for any counterparty which has cheated you in the past, and 0 otherwise.

A sophisticated reputation system could be plugged in here -- if you had information from friends of friends indicating that a given counterparty is unreliable, you could make a handicapper which returns your friend's friend's opinion, and it will be factored in along with the other considerations.

Stuff not covered here

More complicated business decisions, such as which relay server to use and when to drop it in favor of another one, can't be handled with the same mechanism and are currently dealt with on an individual basis. If you are interested in tweaking this kind of logic ask us and we'll set you up.