This is a brief summary of some ongoing discussions about fundamental Interledger topics: the packet format, the addressing scheme, and the protocol layer built directly upon ILP. Ideas are welcome!
Full discussion: Proposal: we need an Interledger Packet -- not just an ILP Header
- Should the packet be:
- JSON
- Binary (CBOR, OER, Protobuf, or custom)
- JSON for now and binary later when we are more concerned with performance
- Only defined semantically, leaving encoding on the wire up to ledger plugins
- Should we define a canonical encoding of the packet? Some higher-level protocols will hash the details in the packet. Should they define their own canonical representation?
- Should the packet be comprised of the ILP details and an array of additional headers, or should all the headers, including the ILP header, be in one array?
- Should we separate headers for end-to-end protocols from routing-related ones?
- Should we support multihoming at the Interledger layer?
Full discussion: How do we address small ledgers/currencies?
- ILP specifies that addresses must match the regex
^[a-zA-Z0-9._~-]+$ - None of the characters technically have special meaning
- There is no requirement or guarantee that addresses are globally unique
- One account may have multilple addresses
- The address convention we are recommending to start is for addresses to be structured as:
neighborhood.subneighborhoods.ledgergroup.ledger.account.subledger.subsubledger - “Neighborhoods” are arbitrary groupings by currency, geography, community, etc.
- Addresses should be chosen such that connectors in the given neighborhood will have routes to the subneighborhood, and so on
- Ledger addresses or prefixes should end in a period
- Ledger addresses should not contain the full address of another ledger. To use a ledger as a routing landmark, its prefix should include a “ledger group” before the ledger part
- “Subledgers” must have a 1-to-1 rate with the ledger they are under
- Given an address, there is no way to determine what each of the segments represent
- Ledger plugins must define a separator so they can extract the account from the part of the address following the ledger prefix (i.e. distinguish account from subledgers)
- Connectors use local routing tables and prefix matching to handle payments and quotes
- Connectors answer quotes with local data if they know the rate to the destination ledger
- Connectors request quotes from other connectors if they do not know the full path’s rate
- Connectors relay payments through other connectors if their ledger prefix does not appear in the destination address
- Connectors deliver the exact amount specified in the ILP header if their ledger prefix appears in the destination address
Full discussion: Proposal: Our transport layers deal with condition generation, memo encryption, ...
- Details required for payment setup
- Payment and data integrity
- Automatic payment retry logic
- Single or streams of payments
- Non-repudiability
- Stateful or stateless receivers
It seems like a good practice for Transport protocols to use an HMAC of some of the ILP packet details to generate the condition/fulfillment. They differ on whether the sender or receiver generates the HMAC key, and how the receiver fulfills the transfer once it is prepared.
- Payment Request Protocol
- Encrypted Key Protocol
- Split Request Protocol
- Split Payment Protocol
- Nested/Repeated Request Protocol
Could add a bullet here that routing tables can contain a route for the empty prefix, also called a "default route".