Messaging in ILP

ilp-messaging.md

ILP and the various higher-level protocols depend on extensive messaging between components. It's important for the messaging protocols to be well defined in order to ensure interoperability.

This includes both the logical data model and the serialization.

ILP requires the following messaging channels and messages:

Client <-> Ledger
    
    -> Request Ledger info
    -> Request list of connectors
    
    -> Request Transfer
    -> Reject Transfer
    -> Fulfill Transfer
    -> Request Account info
    -> Subscribe to events for account
    
    <- Transfer events
    <- Connected/Disconnected events
    <- Error events
    
Client <-> Client

    -> Request Quote

The fact that the five-bells-ledger offers a messaging channel from one client to another is just another transport for the Client <-> Client channel. This could just as easily be a direct client to client connection or a channel brokered through some other intermediary (see ILP Virtual).

It would be valuable to define a standard for the Client <-> Client channel messages as right now the client must assume that if they can submit the message to the ledger to send then the receiver will be able to interpret it. There is no flexibility for the ledger to have a differnt delivery mechanism to different clients or for higher level protocols that wish to leverage this facility to define different serializations/encodings.

There is an implicit standard defined in ILQP (RFC 8) where the quote messages are wrapped in an envelope that gives the message a type and identifier. As there are no other Client <-> Client messages defined yet it is difficult to descern if this is a standard that will be repeated or a one-off.

Proposal: Improve ledger messaging channel to remove the need for an additional layer of abstraction for messaging

1. Add a type property to the ledger message
2. Add an id property

This also provides scope in future for ledgers to implement logic that allows them to route messages via different interfaces based on type. Example: Quote Requests are sent over a synchronous channel and Notifications are delivered via an event-based channel.

The ledger message would change to:

{
  id: "...", //Message id
  to: "...", //Account identifier of destination client
  from: "...", //Account identifier of sending client
  type: "...", //Message type
  data: "..." //Message data (format determined by type)
}

The ILQP request would change to:

{
  "id": "721e4126-98a1-4974-b35a-8a8f4655f934", //Quote id
  "source_amount": "100.25",
  "source_address": "example.eur-ledger.alice",
  "destination_address": "example.usd-ledger.bob",
  "source_expiry_duration": "6000",
  "destination_expiry_duration": "5"
}