Honesty through publicity
=========================
Since essentially this network will be about building trust, I believe that opening the data as well as the mechanism will be the best way to proceed.
The plan is that the courier network database is available at any time - since the only identifiers will be the GPG public key, a BTN account, and an area of operations (AO) code. The source code will also be made available, though that may be through some sort of threshold pledge system. :)
The idea is that if anyone wants to fork the courier network (due to loss of faith, or because they have a better UI, or what have you), they can. This keeps the central database honest and competative, as well as providing some security.
The goal is widespread uptake, not earning a percentage. By keeping the data open, it is more profitable (in the form of donations, or esteem, or what have you) to maintain the network's trust than abuse it by levying fees.
Proposed database architecture
==============================
Courier { Username, GPG Public key, BTN Account, AO code, ... (probably a backup dead-drop email address or other contact method) }
Handoff { GPG Signature by recipient on Courier's public key, ... (probably a 'comments' field, postage involved in this handoff, etc - all signed by the recipient's key) }
There is a many-to-one relationship of Handoffs to Couriers.
Thoughts on risk mitigation for handoffs
========================================
If each courier is required (perhaps by only recieving a fraction of the postage due them) to 'sign off' on receipt as well as delivery of a package, we set up a chain of trust that we can then test.
If the courier network dictates the place the trade will take place (think geohashing [1]) - we can also send "null packages" to test the courier's reliability rating. Other nodes in the local AO can also be elected 'auditors' to send test packages as well.
Having these network audits happen randomly as a percentage of packages will help convince couriers to stay honest.
Penalties
=========
Couriers failing an audit will lose their entry in the database, with its accumulated network trust. As postage fees will scale based on the level of trust, there will be a lot to lose by failing an audit. Please note that this in no way obligates a courier to take a job - it's failing an audit that drops them from the network.
Couriers that repeatedly try to game the system by dropping their persona and creating a new one can either be punished through charging an entrance fee to become a new courier in an AO, and/or an AO can take up a collection for an audit majure [2].
In future, 'taxes' on couriers in the AO could be gathered for maintenance of an audit/enforcement squad whose job is protecting the network and resolving disputes.
'Taxes' might also be levied in order to provide insurance on packages - though this will likely presuppose the existance of audit squads, as it doesn't appear that there is a way to provide insurance programatically that can't be gamed.
Indoctrination
==============
Couriers just starting out are going to have a trust threshold to cross - there are ways to handle this outside of just scaling postage alongside number of successful trades.
Sponsors are one idea.
Public webcams set up in advance at a location for pickup, and then sending a null package can verify that someone did in fact show up.
Having the courier take a picture of the dropoff location with the package? This would prove a time/place/package/courier relationship, though not prove that the package was not tampered with or stolen outright. May be useful for disputation with the local audit squad.
Street view could be used to choose a remote location in advance. Coupled with the above pictorial evidence and time constraints, we can increase the amount of work it will take to intercept a package.
Uptake
======
I've already gotten PMs from several interested parties, and started making local contacts aware of BTN. Any commentary on this is welcome - _especially_ any glaring security holes that haven't been addressed, or additional things that should be tracked in the database.
Bibliography
============
1. Geohashing
http://irc.peeron.com/xkcd/map/ http://www.xkcd.com/426/2. Audit Majure
http://tinyurl.com/yh5jdd/
