OTTP URI Format
a link should be able to perform the following:
1 Send a Nym a Message. ex.
2 Transfer funds. ex.
OTTP://src=234jjk234kj234jk23l423;dst=34nnskfsdui923jkwekrjfsd;amt=234.344. also supports 'default' accounts which are set in the GUI, so the web app does not have to specify what the src account is. This most likely is the most common usage. Web developers will want an easy way to trigger a payment from one account to another. In addition to initiating simple transfer functions, it can also pass in a message to the GUI to allow for more friendly CONTEXT SPECIFIC messaging to the GUI so the user feels more comfortable with the transfer. For instance the link will have another field, htmlmsg that has HTML data that displays nice graphics and confirms with the user to whom they are about to pay and for what reason. This HTML will appear IN THE OT GUI, and that is key for user confidence. There may also be other, simpler ways of performing messaging that do not require such verbose links. Similar formats can be developed for chaumian transfers and can easily be supported in the GUI.
OTTP://src=SRCACCOUNT;dst=DSTACCOUNT;amt=123.44;msg=<div><h1>You are about to pay FellowTraveller E-Banking Services</h1><p>please confirm</p><img src="fellowtraveller-logo.gif"></div>
Account Number Deferral
The web server need not know the account number or Nym of the user. It's important to allow for this functionality in order to support anonymity, as web site owners can then link an account with a IP address and other identifiable information. Also it is possible to have a OTTP link that performs simple actions like payment or account transfer, without any prior knowledge about the user. The links themselves can refer to a NAME (discussed also in GUI Notes) , which is set in a variety of ways in the GUI (often times by default). Thus links do not have to contain specific Account numbers.
this also exposes the user to IP tracing because the web site can simply correlate payments and web usage and link the records. Thus security features such as Tor and time-deferment of payment can be employed. NAMES can also be dependent on the REFERRER domain (the web site they live in) , as for instance the user may want a default account for one web site and a default account for another. It should be noted however, that in order to maintain security the* Server and the Web Site should be different, unrelated parties*.
In order to facilitate E-Commerce, links that enable transfers must have an added feature- that of a linkback to a 'success' page. In other words, after the payment is processed, then the web application must have a way of responding to that. This pattern can be seen in a PayPal link found throughout the web.
also, some file types in hyperlinks will trigger the gui. for instance, checks, cash, vouchers can be embedded as files in web pages(or attached to emails) and be picked up automatically when clicked. ie. The voucher will be downloaded as a file, the GUI will pick it up, prompt the user, and inform the user the voucher has been processed. This also suggests another important usage: Web Servers will be generating vouchers, checks, cash and other instruments so these functions need to be available to web scripting languages such as PHP.
this means we need a special file type suffix and that suffix needs to be associated with the GUI application.