michielbdejong
commented
5 years ago I guess this is not so high priority at the moment until we expect more than two or three browser extensions might support the ledger protocol, and that some browser extensions would use any protocol on top of the ledger messaging other than ledgerloops-0.8. If it's just for signalling ledgerloops-0.9, we can do that with the WebSocket protocol.
maybe specify the protocol at the WebSocket level? And then in order to register the link-rel, the generic "ledger" protocol should also be described somewhere, for instance in an internet draft. Maybe the ADD/ACK/COND/FULFILL/REJECT part is generic enough, and the PROBES and PLEASE-FINALIZE parts can be versioned as "LedgerLoops-specific" messages on top of that? If the Fulfiller decides about timing, then timeouts are implicitly supported.
process: Alice puts new transaction into PENDING state, starts sending ADD or COND messages. If/when Bob receives the message, he can put it in the PENDING state too. Bob can respond with an ACK/FULFILL/REJECT and put the transaction in the COMMITTED state If/when Alice receives the response, she also puts it in the COMMITTED state, If Alice feels the response takes too long, she can repeat the message to retry triggering Bob's (repeated) response. That way, if either the message or the response were lost by temporary network trouble, they eventually get recovered.
PENDING / UNKNOWN PENDING / PENDING PENDING / COMMITTED COMMITTED / COMMITTED
Each transaction has a currency and an integer amount. There are two pending balances and one committed balance. Balances add up as you would expect, and rejected transactions roll back.
Current balance may play a part in deciding whether to accept a new transaction, as would cond/fulfillment and timing.
Since the fulfiller decides about the vailidity, maybe ADD and COND can be merged and FULFILL can be merged with ACK.