Interledger [Forum]
External Links

- ILPv4 whitepaper:

  RFCs issues
  RFCs Pull Requests
- Home
- ASN.1

ºTutorials and guides:º
- Glossary

- (Partially outdated)Interledger Presentation @ Workshop Berlin
- free introductory course on cryptography for programmers of all ages
- Original white paper ("Outdated", -many, many changes from the original vision-)

ºCommunity channelsº
- Chat: here to Interledger developers and protocol architecs)
- public-interledger@W3C mailing list(low activity)
- Hyperledger Quilt@Linux Foundation(Talk here to Java Quilt developers)
- More info

ºCommunity meetingsº
- General ILP Protocol Biweekly community meetings -bluejeans- (Windows/Android/iPhone)
- Java "Quilt" Developpers meeting

ºDevelopment Linksº
- Binary ASN1 Definition of ILP packets
- GitHub repositories for (reference Implementation) NodeJS code
- GitHub repositories for Java implementation ("Hyperledger Quilt")
- Interledger Payment method for W3C browser Payment API
- NodeJS Tooling:
  - Visual Code Studio is the recomended IDE for NodeJS development
  - allows to easely run NodeJS in a dockerized enviroment (and change the default node version used if needed)

- Java Tooling:
  - IntelliJ, Eclipse or Netbeans have been used with no major problems.
    IntelliJ is recomended when using Kotlin

Java Devel. Links:
- Nicholas Dudfield(Sublimator)repos including Java Ripple client
- Initial Java Support for XPR Blockchain: XRP client 
- ILP over Ethereum
- Sharafian Ethereum JS connector Plugin
  Bitcoin/LiteCoin/Zcash JS connector plugin
          (ILP)             (IP)
│Application│SPSP  HTTP-ILP  │HTTP SMTP .. │
│Transport  │    STREAM      │ TCP   UDP   │
│Interledger│      ILP       │          IP │
│Link Layer │BTP             │   Ethernet  │
│           │ILP-over-HTTP   │   WiFi      │
│ Harware   │ledger/connector│host/router  │
Link layer protocols in ILP are implemented by software plugins.
Link layer protocols in IP  are implemented by hardware.
ILP Timeline Evolution
- REF:
- Interledger as a SETTLEMENT System (ORIGINAL VIEW)
  - ILP cryptography support on settlement ledgers.
  - Ledgers will have support for conditional transfers and are fast enough.
  - Trust-lines are an unusual type of ledger.

- Interledger as a CLEARING System. ILPv4 (CURRENT VIEW September 2017+)
  - connectors as central actors acting as "clearing houses"
  - NORMAL CASE: connectors have some credit/trustlines relationship
    with each other. ILP payments go through them
  - UNUSUAL CASE:  You send every transfer through some ledger
  - ILP: try to standardize the clearing protocol
    entitities needed by connectors to clear payments:
    [transfers, fulfillments, rejections, quotes, route broadcasts]
    º"""settle is completely divorced from clearing payments""".º
  - Individual payments are almost always broken up into multiple smaller packets

 - LAYER 0: ability to send paid paquests(requests), and conditionally paid paquets(requests)
 - LAYER 1: ILP Address namespace to route packets
 - LAYER 2: Data on top of ILP. Ability to send/receive paid data by
            just connecting to the ILP network.  (Stream services, PaaS, ....)
 - """(Evan Schwartz)...An argument here is that the reason IPv6
   didn't really take off was because it offered relatively minor
   improvements over IPv4. In contrast, ILP introduces the ability to
   send value as well as information and the ILP Addresses are much more
   flexible even than IPv6 addresses."""

Packet Data Layout
╭─┬─┬─┬───────────────────╮ ╭─┬─┬─────────────────────╮ ╭─┬─┬─────────────────────╮
│ │ │ │Application Packet │ │ │ │                     │ │ │ │                     │
│ │ │ ╰───────────────────┤ │ │ │                     │ │ │ │                     │
│ │ │Stream Packet        │ │ │ │DCP Packet           │ │ │ │RBP Packet           │
│ │ ╰─────────────────────┤ │ │ ╰─────────────────────┤ │ │ ╰─────────────────────┤
│ │ILP Packet             │ │ │ILP Packet             │ │ │ILP Packet             │
│ ╰───────────────────────┤ │ ╰───────────────────────┤ │ ╰───────────────────────┤
│BTP Packet               │ │BTP Packet               │ │BTP Packet               │
╰─────────────────────────╯ ╰─────────────────────────╯ ╰─────────────────────────╯
- who is in TestNet
  (your node will appear if you add it through the '?test=')

  - Michael test ledgers: '' AND ''

- Testnet-of-Testnets WiKi
- Testnet desing
- e-mail Michiel de Jong
    """As discussed ..., we started building a testnet. You can now
     choose your node's home ledger to be part of live network (prefix
     `g.`) or testnet (prefix `test.`). We ask everybody who runs a
     connector to situate their connector firmly on one side of that
     divide, so either you connect only between `g.` ledgers, or you
     connect only between `test.` ledgers. """

   list different testing faucets for
   and test-case scenarios from simplest to the more complex ones:
   - baseline: pay to any testnet
   - step 1: baseline connector
   - step 2: multi-hop
   - step 3: end-to-end
   - step 4: routing
   - step 5: sender-paychan
   - step 6: receiver-paychan
   - step 7: bidirectional-paychan

- "Ping" people at Gitter Lobby to set up peering!

See also:
- [DevOps]Terraform tier2 ilp-connector
RFC-0015 ILP Address
- Every ledger or blockchain account is asigned a "mostly unique" ILP
  Address.  Since there is no central authority goberning ILP address
  asignation collision between ILP addresses is possible but that
  collision will be detected soon since payments are also protected by
  sha256 hashes.  (An ILP payment arriving to wrong recipients will not
  match the pre-acorded sha256 hash)

- ILP addresses provide a mechanism to route payments to their
  intended destination through a recursive series of ILP network nodes.
- Destination Addresses are complete addresses that can receive
  payments, always mapping to one account in a ledger
- Addresses Prefixes are INcomplete addresses representing a group of
  destination addresses, or a connector node
- See @[]
  for more info about different type of addresses, allocation
  schemes, requirements and REGEX

ºExternal Linksº
- @[]
- @[] Proposal: ILP Address Mapping
- @[] Proposal: Connector forwarding/delivery distinction
- @[] (Addressing small ledgers/currencies
- @[]
   (explains the different representations for unique AccountID)
- Mailing Threads:
  - @[]

ºTrust-lines / Payment Channelsº
- Trust-line: Virtual ledger established amongst peers that keeps a
  temporal balance that periodically gets sincronised with the (real)
  settlement ledger
  Trus-lines can be divided into:
  - asymmetrical trustline: ledger with two account holders,
    and one of them is also the ledger administrator.
  -  symmetrical trustline: ledger with two account holders,
    who collaborate on an equal basis to administer the
    ledger between them.

- Payment-channel: A trust-line with the support of
  a blockchain or cryptographic system to secure/enhance
  Lightning and 
  Ripple XPR Channels are two well known examples.
  More info and theory about them can also be found in the
  Bitcoin wiki

- RFC-PR: Payment pointers
- P.R.:
  - standardized identifier for accounts that can ºRECEIVEº payments.
  - A payment pointer can be resolved to an "https" URL that provides
     the location of a payment setup service endpoint
     (previous step to payment)
  - (design goal): It's used for (pre)payment setup protocols BUT
      it should be possible for any new payment setup protocol to "reuse"
      payment pointers.
  - The syntax of a payment pointer is (ABNF):
      "$" host path-abempty
    The corresponding URL will be
      "$" host path-abempty
(empty path-abempty is replaced by /well-known/pay)
RFC-0027 ILPv4
Sender €      Connector 1     Connector 2     Receiver $  ║ Plugin Interface summary:
               € ←→ ETH        ETH ←→ $                   ║
     ºSTEP 0: Network setup (Connectors Setup)º           ║                 
│               │               │               │         ║
│               │── connect ──→ │               │         ←  plugin.connect()     creates a channel via on chain transaction
│               │←─ connect ─── │               │         ←                       (if it doesn't exist already)
.            (Connection established)           .         ║                       Connect is "misleading" since it can actually
·                                               ·         ║                       means "listen for client connections"
·                                               ·         ║                       depending on the underlying network/RPC protocol.
·                                               ·         ║                       For example, for HTTP based protocol, a connector
.                                               .         ║                       will act as HTTP server, and in the connect phase
·                                               ·         ║                       it will just stay listening for peer connections.
·                                               ·         ║                       Peer connectors will actually connect to a long
·                                               ·         ║                       running HTTP session on the .connect() phase.
Sender €      Connector 1     Connector 2     Receiver $  ║                            
│              € ←→ ETH        ETH ←→ $         │         ║
│    ºSTEP 1: Payment SETUPº                    │         ║
├ ←── sender and receiver agree on payment ───→ ┤         ║                      This could be done through estandar HTTP protocols like SPSP,
│     amount, destination address and           │         ║                      with no intervention of the connectors/connector plugins:
│     condition (=sha256 of fulfillment)        │         ║                      (Some extensions to ILP can use a "mock" payment that actually "cross" 
                                                .         ║                       through the ILP network to get the best exchange price among 
·                                               ·         ║                       concurrent ILP connectors providing liquidity for the currency 
·                                               ·         ║                       exchange )
·                                               ·         ║
Sender €      Connector 1     Connector 2     Receiver $  ║                            
│              € ←→ ETH        ETH ←→ $         │         ║
│    ºSTEP 2: START ILP Paymentº                │         ║  
├── sendData──→ │               │               │         ║  plugin.sendMoney()   creates and sends a paychan claim via BTP/ILP-o-HTTP/...
│               │               │←─ fulfillment─┤         ║                       (probably locking money and setting a timer)
│               │               │               │         ║
│               ├── sendData──→ │               │         ║                                                                   
│               │               │               │         ║
│               │               ├── sendData──→ │         ←  
│               │               │               │         ←  plugin.handleMoney() recieves paychan claims via BTP/ILP-over-HTTP/...
│               │               │←─ fulfillment─┤         ←                      and checks they are valid
│               │               │               │         ║                       (probably unlocking money and closing timer) 
│               │               │               │         ║ 
│               │←─ fulfillment─┼─ sendMoney──→ │         ←                       unlock money, clear timer set at .sendMoney()
│               │               │               │         ║ 
│←─ fulfillment─┼─ sendMoney──→ │               │         ←                       unlock money, clear timer set at .sendMoney()
│               │               │               │         ║ 
├─ sendMoney──→ │               │               │         ║
·                                               ·         ║
·                                               ·         ║  
Sender €      Connector 1     Connector 2     Receiver $  ║  
               € ←→ ETH        ETH ←→ $                   ║
         ºDisconnect peer Connectorº                      ║
│               │               │               │         ║
│               │─ disconnect → │               │         ←  plugin.disconnect()  closes out the channel by submitting, on chain,
│               │←─disconnect ─ │               │         ║                       the last stored claim
.            (Connection established)           .         ║
Code references
- five-bells-condition/src/lib/condition.js
- five-bells-condition/src/lib/fulfillment.js


Quoting Protocol
ºQuoting (protocol)º:
  - Allow senders to determine exchange rate between
    their assets (for example USD) and the receiver's
    assets (for example EUR) before making a payment

  - decimal_digits: a hint for GUIs, the conventionally displayed
    number of decimal places for a given asset.
  - Precision: number of digits in a number.
  - Scale: number of digits to the right of the decimal point in a
  - Examples:
    - 123.45 has a precision of 5 and a scale of 2
    - a USD ledger might use a precision of 15 and a scale of 6 and 2
ILP Payment
- An payment consists of an ordered (in time) list of local transfers
  between connectors.
- The execution of each local transfer is coordinated by the ILP protocol
- REMOTE TRANSFERS + SETTLEMENT diagram using escrow +
├───┼────────────────────────────────┤ O ├───────────────────────────────────┤
│   │                                │ N │                                   │
│↓  │                                │ N │                                   │
│T 1│ sender → (amount1) → hold      │ E │                                   │
│I 2│                                │ C │ connector → (amount2) → hold      │
│M 3│                                │ T │ hold      → (amount2) → recipient │
│E 4│ hold   → (amount1) → connector │ O │                                   │
│↓  │                                │ R │                                   │
↑                ↑                                      ↑
│                └── amount1 (inbound ammount) must ────┘
│                be greater than amount2 (outbound ammount)
│                  for the connector to have any profit
└ local transfers 1, 2: PREPARE   PHASE
local transfers 3, 4: EXECUTION PHASE
- In the PREPARE PHASE the crypto-condition is "linked" to the payment
  and execution is conditioned to receiving the fulfillment
  (fulfillment == "cryptographic receipt") before a timeout
- In the universal (non-atomic) mode it's possible for a timeout
  in ledger1 in step 4 after step 3 is executed properly in ledger 2.
  In that case ledger 2 looses money.

- An external "clock" (notary, orderer, oracle in blockchain nomenclature
  or transaction manager -DDBB nomenclature-) is needed for full atomic-mode
boxes represent local ledger TXs or trust-line rebalance
amt1 = ammount1, amt2 = ammount2, amt3 = ammount3

    LEDGER1       CON1         CON2      LEDGER2   LISTENING
     |           |←TrustLine→|           |        APP for dst
┌──────────────┐ |           |           |         account
│send→amt1→hold│ |           |           |            |
└──────────────┘ |           |           |            |
     +-sendData-→|           |           |            |
     |           |-sendData-→|           |            |
     |       ┌─────────┐ ┌─────────┐     |            |
     |       │IOY-=amt2│ │IOY+=amt2│     |            |
     |       └─────────┘ └─────────┘     |            |
     |           |           |-sendData-→|            |
     |           |           |    ┌──────────────┐    |
     |           |           |    │con2→amt3→hold│    |
     |           |           |    └──────────────┘    |
     |           |           |           |-condition-→|
     |           |           |           |←fulfillm---|
     |           |           |    ┌──────────────┐
     |           |           |    │hold→amt3→dst │
     |           |           |    └──────────────┘
     |           |           |           |
     |           |           |←fulfillm--|
     |           |←fulfillm--|           |
     |       ┌─────────┐ ┌─────────┐     |
     |       │IOY+=amt2│ │IOY-=amt2│     |
     |       └─────────┘ └─────────┘     |
     |←fulfillm--|           |           |
┌──────────────┐ |           |           |
│hold→amt1→con1│ |           |           |
└──────────────┘ |           |           |
- inbound amount decreases from hop to hop. If it get lower than destination
  amount in the ILP header payment will be rejected.
- For connector 1/2 to have profit (and mitigate risk if payment is not atomic):
      ammount1 greater than ammount2 greater than ammount3
→ POST / HTTP/1.1
→ ILP-Destination: g.crypto.bitcoin.....
→ ILP-Condition: x73kz0AGyqYqhw/c5LqMhSgpcOLF3rBS8GdR52hLpB8=
→ ILP-Expiry: 2017-12-07T18:47:59.015Z
→ ILP-Amount: 1000
(end-to-end binary data body 32767 Bytes max)

NOTE: ILP-Expiry and ILP-Amount change at each "hop"

→ HTTP/1.1 200 OK     | → HTTP/1.1 400 Bad Request
→ ILP-Fulfillment: ...| → ILP-Error-Code: F02
→ Content-Length: 0   | → ILP-Error-Name: no route found
                      | → ILP-Error-Triggered-By: g.xrp...
                      | → ILP-Error-Message:
                      | → Content-Length: 0
                      | →

ºDevelopment Linksº
- NodeJS implementation
- Everconnector Plugin
- Alternative to ILP-over-HTTP using a binary protocol
    """BTP is just a wrapper around ILP packets that makes it
    easier to send them over WebSockets...
    ... I guess the advantage of HTTP is that it's easier (to implement).
    The Advantage of WebSockets is that it allows a client (so a computer
    that's not publicly addressable, e.g. a laptop or phone) to be a receiver,
    and that some JavaScript-based connectors may only support WebSockets
    (but if a JavaScript-based connector wants to peer with a Java-based one,
     it would be easy to add ilp-plugin-http)"""

- BTP Sub-protocols include optional functionality like ledger
  metadata, balance, automated settlement, and dispute resolution.

- BTP Connection: websocket connection over which BTP packets are
                  sent. Websockets (as opposed to raw TLS sockets)
                  are used because they provide message framing and
                  can be used from the browser.
- BTP Packets   : protocol data units formally defined in ASN.1
- Peers         : are the parties on a BTP connection. Your peer is
                  the party on the other side of the BTP connection.

- request is In-Flight : if the request has been sent out, but no
                  response has been sent yet
- transfer is In-Flight: if it has been prepared but not yet
                  fulfilled nor rejected

- BTP-toolbox for building and debugging with the BTP
- """I'm using the tf-connector repo to set it up. What do we need to
     do to connect ?
     Michiel de Jong @michielbdejong Jan 29 21:42 @rhuairahrighairidh
     cool! i think you could configure an ilp-plugin-btp instance with
     { server: 'btp+wss://:˂token˃' }
     and relationship 'parent'. i haven't tried tf-connector myself yet,
     though, so let us know if you run into any trouble configuring that! """
ILDCP: stands for Interledger Dynamic Configuration Protocol
- protocol used for transferring node⅋ledger information from a
  parent node to a child node. The transferred information is:

  - ILP address that the child should use for its own address  :
  - Asset code that the two nodes will use to settle           :
    e.g.  XRP
  - Asset scale used in ILP packets exchanged between the nodes:
    e.g.  6

child  → parent: requests configuration information in ILP packet
                 type     : ILP Prepare (type id: 12)
                 condition: SHA-256 hash of zero-filled 32 byte octec string
                            (Zmh6rfhivXdsj8GLjp+OIAiXFIVu4jOzkCpZHQ1fKSU= in Base64)
                 ILP Address: peer.config
                              ^ peer used for bilateral protocols in ILP
                 Amount: 0 ← default for all ILDCP implementations
                             In future, peers may agree to pay a charge for reserving
                             an address, in which case this may become a non-zero amount
                             indicating the amount paid by the child to reserve an address.
                 data:        empty (size: 0)
parent →  child: configuration information (or error*1) in ILP packet
                 type       : ILP Fulfill (type id: 13)
                 fulfillment: zero-filled 32 byte octet string
                 data:        specific format described by
                              DynamicConfigurationResponseData in
                              the ILDCP ASN.1 definition. OER encoded SEQUENCE-of
                              - Variable-length octet string: An ILP address that the
                                child should use, encoded as an ASCII string
                              - Uint8: An unsigned 8-bit integer indicating the asset
                                scale that should
                                be used for packets exchanged with the parent
                              - Variable-length octet string: An asset code, encoded
                                as a UTF-8 string, indicating the settlement asset used
                                between the peers
                 expiresAt:   arbitrary/ignored

   - type: ILP Reject (type id: 14)
   - code: an appropriate error code
   - message: appropriate human-readable message for debugging
   - triggeredBy: ILP address of the parent node
   - data:  empty (size: 0) or MAY contain further information for
     debugging the error.

ºASN.1 Definitionº
The ASN.1 definition of ILP packets is described in
InterledgerProtocol.asn and Dynamic Configuration Protocol data in

ºJavascript Implementationº
Transport Protocols
- A critical function of Interledger Transport Protocols is to determine
    the path exchange rate and handle any changes in the rate.

- Senders SHOULD judge amounts and prices only in their own units
    using the calculated path exchange rate, because destination units can
    be manipulated by the receiver (by using a connector with an exchange
    rate they control).

- Implementations SHOULD use the ratio of the amount that arrived at the
    remote endpoint and the amount sent to determine the path exchange rate.
    They MAY send an unfulfillable test packet when the connection is
    initiated to estimate the path exchange rate.

- Implementations SHOULD set the minimum acceptable amount in each packet
    sent to prevent the remote endpoint from accepting a packet if the exchange
   rate was worse than expected.

- Implementations SHOULD NOT fulfill incoming Prepare packets with amounts
   less than is specified in the STREAM packet.
(replaces PSK2)
Multiplexed Money& ILPv4 Data Transport Protocol

- reliably sends money&data over ILP.
- All STREAM packets are encrypted using AES-256-GCM with a 12-byte
  Initialization Vector (IV) and a 16-Byte Authentication Tag
- Use-cases:
  - streaming payments and/or data
  - Segmenting larger discrete payments and messages into packets and
    reassembling them
  - Bi-directional communication between two endpoints through ILP
  - Stream multiplexing (sending multiple logical streams of money
    and/or data over a single connection)
  - Stream- and connection-level flow control (adjusting the rate at
    which money and data are sent)
  - Congestion control (adjusting the rate at which ILP packets are
    sent based on network throughput limits)
  - Authenticating and encrypting ILP packet data
  - Generating and fulfilling ILP packet conditions
  - Connection migration

A ºvirtual connectionº is established between "client" and a
"server" that can be used to send authenticated ILP packets between
them. That virtual connection is represented by session-data in both
end-points generated through a single shared secret

- Like PSK2, STREAM ºuses a shared secret to authenticate and º
 ºencrypt multiple packets, as well as to generate theº
 ºconditions and fulfillmentsº.

   In addition, STREAM enables bidirectionaly sending money and data
  and automatically determines how much money and data can be sent in
  each ILP packet.
ºSTREAM borrows heavily from QUIC's packet formatº
    Stream-ID: Allow different streams to be multiplexed over a single connection

    Client   : The endpoint initiating a STREAM connection
               Client-initiated streams are given odd-Stream-ID-numbers starting with 1
    Server   : The endpoint accepting incoming STREAM connections
               Server-initiated streams are given even-Stream-ID-numbers starting with 2

    ConnectionMaxStreamId: Allow to limit max number of concurrently active incoming streams.
               This parameter must be announced to the peer end-point.
               Implementations SHOULD use a default max stream ID of 20
               (allowing each endpoint to open up to 10 concurrent streams)

    Sender -  endpoint that ºsends a particular ILP Prepare packetº.
    Receiver - The endpoint that receives a particular ILP Prepare packet
              and ºresponds with either an ILP Fulfill or Reject packetº.
              A Fulfill response is equivalent to a Packet Acknowledgement (ACK) while
              a Reject response is equivalent to a Packet No-Acknowledgement (NACK)

    ºOnce STREAM connection is established client and server become "peers" and canº
    ºbecome senders or receiversº
    STREAM packet - ºencoded, encrypted and sent as the data field of an (º
         ºPrepare|Fulfill|Reject)ILP-packetº that can be parsed by a STREAM endpoint

    Streams are given numerical IDs to allow stream multiplexing over a single connection.

Application Layer protocols, (SPSP,...) can use STREAM to send money and data between endpoints.

  STREAM packets include a minimum acceptable amount in ILP Prepare
  packets and the amount that arrived
  at the other endpoint in the response Fulfill/Reject packet.

- Each STREAM packet consists of multiple Bºframesº,
  which can be used to send money, data, or
  control-related information.

Connection-Life-Cicle (Creation, use, closing) ºMATCHING PACKETS TO CONNECTIONSº - Incoming packets can either be associated with an existing connection, or, for servers, potentially create a new connection. - Endpoints MAY append extra segments to the ILP addresses assigned to them by their upstream connectors to help direct incoming packets. Client → server: ConnectionNewAddress-frame indicating Client-ILP-address Server → Client: (Using encrypted communication channel like HTTPS) (Key exchange is NOT provided by STREAM) - STREAM Version (optional -- assumed to be version 1 unless specified) - Server ILP Address - Cryptographically secure random or pseudorandom shared secret (it is RECOMMNEDED to use 32 bytes) NOTE: To avoid storing a 32 byte secret for each connection, a server MAY deterministically generate the shared secret for each connection from a single server secret and a nonce appended to the ILP Address given to a particular client, for example by using an HMAC. HANDLING INCOMMING PACKET: connector → receiver: STREAM packets receiver → receiver: - decrypt&parse STREAM packet - Reject packets with "F06: Unexpected Payment" when data cannot be decrypted with expected shared secret errors. ENDPOINT ILP ADDRESS CHANGE AFTER INITIAL CONNECTION: endpoint1 → endpoint2: ConnectionNewAddress-frame indicating new peer-ILP-address - To ensure the new address is received and acknowledged, implementations MAY choose to send these frames only in ILP Prepare packets. endpoint1 → endpoint1: Wait for valid response (encrypted with the same shared secret) from the new address to validate the new path. NOTE: STREAM uses the authenticated request/response packets in lieu of QUIC's explicit Path Validation. Implementations SHOULD refrain from sending large numbers of packets or large amounts of data to a new ILP address before validating the path to avoid being tricked into participating in a Denial of Service (DoS) attack on a third-party endpoint. OPENING NEW STREAMS -- connection already established, either endpoint can create streams to send money or data-- endpoint1 → endpoint2: (StreamMoney|StreamData)-frame with a previously unused stream ID. SENDING MONEY endpoint1 → endpoint2: ILP-Prepare-packet with non-zero amount + STREAM packet containing StreamMoney-frame to indicate which stream the money is for. NOTE: A single ILP Prepare can carry value destined for multiple streams and the shares field in each of the StreamMoney frames indicates what portion of the Prepare amount should go to each stream. ----------------------------------------------------------------------- SENDING DATA endpoint1 → endpoint2: ILP-Prepare-packet + STREAM packet containing StreamData-frame NOTE: A single ILP Prepare can carry data destined for multiple streams. ----------------------------------------------------------------------- ºFLOW CONTROL TYPESº ------------------- STREAM-LEVEL: Allows an endpoint to limit the amount of incomming money and data on a particular stream. CONNECTION-LEVEL: Allows an endpoint to limit total the amount of incomming data on all streams. ºCLOSING STREAMSº endpoint1 → endpoint2: StreamClose-frame (normal or error) Implementations MAY allow half-open streams (one side has closed, the other is still able to send) ºCLOSING CONNECTIONSº endpoint1 → endpoint2: ConnectionClose-frame (normal or error) Implementations MAY allow half-open connections (where one side has closed the connection and the other is still able to send). See @[] for Packet and Frame Specification and Encryption details ºENCRYPTION PSEUDOCODEº - encryption key used for every packet sent for a given connection is the HMAC-SHA256 digest of the shared secret and the string "ilp_stream_encryption", encoded as UTF-8 ( or ASCII since they match) var iv = random_bytes(12); var encryption_key = hmac_sha256(shared_secret, "ilp_stream_encryption"); var { ciphertext, auth_tag } = aes_256_gcm(encryption_key, iv, data);
JS Implementation @[]
Application Protocols
Payment Pointers

ºABNF Payment Pointer Syntaxº
"$" host path-abempty → "https://" host path-abempty
                                         ^ /.well-known/pay for path-abempty "/" or "empty"
                      ^ - Payment Pointer ºHTTP GET Endopointº resolution
                        - Sending clients ("wallets") must resolve
                          it and perform the http GET request
                          (adding supported Payment protocols in the
                           Accept header of the request. Ex
                           Accept: application/spsp+json )
ºCharacter set limited to valid ASCII characters. º

  $                →
  $ →
  $            →
  $            →

See example Quilt implementations:

ºSPSP: Simple Payment Setup Protocol (SPSP)º
Basic protocol targeting end-user apps for ºexchanging payment
informationº between senders and receivers in order to facilitate
payment details (ILP address, shared secret, ...) using HTTPS to
exchange SPSP messages

SPSP uses the STREAM transport protocol for condition generation and
data encoding.

Notice the creation of a new  STREAM payment needs also basic
receiver details provided by SPSP.

- sender digital wallet using SPSP to initiate payments.
- SPSP clients and receivers use ILP modules to send and
  receive Interledger payments.
- SPSP payment-pointers can be used as a persistent identifier
  on Interledger. SPSP payment-pointers can also be used as a unique
  identifier for an invoice to be paid.

-------- Pre-setup -----
SPSP receiver → HTTPS Server: Create/expose SPSP (HTTP GET) Endpoint
SPSP receiver announces SPSP Endpoint to sender by any method/channel
(sender and receiver use the STREAM transport protocol to generate the ILP packets)
-------- Payment pre-setup -----
SPSP_sender   → SPSP_Endpoint: query type-of-payment information available for reciever
SPSP_sender   ← SPSP_Endpoint: response including (receiver's ILP address, shared secret),...
                               Optionally can include:
                               -  balance associated with SPSP receiver, i.e. in the case of an invoice.
SPSP_sender   → SPSP_receiver: constructs ILP payment
-------- Start Payment -----
(SPSP_sender←→SPSP_receiver) → +ILP/STREAM_connection:
SPSP_sender  → ILP/STREAM_connection:  +STREAM-stream
SPSP_sender  → ILP/STREAM_connection:  adjust sendMax to reflect max amount they're willing to send
SPSP_receiver→ ILP/STREAM_connection:  adjust receiveMax to reflect the amount they're willing to receive

The sender's and receiver's STREAM modules will move as much value as
possible while staying inside these bounds.  If the sender reaches
their sendMax, they end the stream and the connection. If the
receiver reaches their receiveMax, they will end the STREAM and the

Sender SHOULD treat the URI as opaque:
There are several supported ways to refer to an SPSP endpoint:
  - Payment-pointer : (    Recommended) $, $,...:
                      - SHOULD be the only kind of SPSP identifier exposed to users(GUIs).
  - Raw endpoint URI: (Not recommended):  https://.../spsp/alice.
                      - SHOULD NOT be exposed to users (GUIs),
                      - SHOULD be supported by SPSP clients.

SPSP Endpoint MUST respond to HTTPS GET requests in the following manner:

→ GET /.well-known/pay HTTP/1.1
→ Host:
→ Accept: application/spsp4+json, application/spsp+json

← HTTP/1.1 200 OK
← Content-Type: application/spsp4+json
← Cache-Control: max-age=Num_of_seconds|no-cache

← {
←   "destination_account": "",
←   "shared_secret": "6jR5iNIVRvqeasJeCty6C+YB5X9FhSOUPCL/5nha5Vs=", (32 bytes, base64 encoded, including padding
←   "balance": {            (optional)                                SHOULD be different in each response to avoid
←     "maximum": "100000",                                            broken implementations, """if someone else gets
                                                                      to see the same shared_secret as you, then it's
←     "current": "5360"                                               no longer secret""")
←   },
←   "asset_info": {         (optional)
←     "code": "USD",
←     "scale": 2
←   },
←   "receiver_info": {      (optional)
←     "name": "Bob Dylan",
←     "image_url": ""
←   }
← }
ºNote: Currency amounts are denominated as integer strings instead of native JSON º
ºnumbers to avoid losing precision during JSON parsing. Applications MUST         º
ºrepresent these numbers in a data type that has precision equal or greater       º
ºthan an unsigned 64-bit integer.                                                 º

- Launch SPSP service
- Payment-pointer tutorial
1 Create your payment pointer:
$ npm install -g ºilp-spsp-serverº
$ DEBUG=* ilp-spsp-server \
  - -subdomain michielbdejong

2 Pay yourself
$ npm install -g ilp-spsp
$ DEBUG=* ilp-spsp send - \
  -receiver '$' \
  - -amount 100

You should see something like:
 paying 100 to "$"...

ºCode implementationsº
- (sharafian@Ripple) SPSP JS implementation using PSK2 (Updated to STREAM?)
- ILP-Butterfly Minimal browser ILP/SPSP client
- ILP-Butterfly Minimal browser ILP/SPSP client
-  Fully client-side app for sending Interledger payments from the browser.
    It uses the ILP Client and the
  ILP Plugin RPC
  to send Interledger payments from the browser
Fragment/Stream payments
- 1
- Testing: Setting up a testnet
- PR #309: Replace ILQP with End-to-End Quoting
- primarily designed for individual payments (vs streams payments)
- It allows a sender to determine the exchange rate between their
  ledger and the receiver's ledger "on demand" (just before starting
  the payment).
- PR #309: Replace ILQP with End-to-End Quoting
- end-to-end protocol implemented by Interledger senders and
  receivers (not connectors, in contrast to ILQPv1)
- ILQPv2 assumes all connector exchange rates are linear and that
   there are no fixed fees (no Liquidity Curves)
- Senders may use a dedicated quoting module or ILQPv2 may be
included in a Transport Layer protocol
  sender -> receiver: specially crafted
                      test payment
  receiver -> sender: reject + specific
                      error message

- connectors MUST ignore the amount in the ILP Packet, and neither
  attempt to deliver the exact amount in the packet or reject payments
  where the transfer amount is lower than the amount in the packet and
  MUST relay error messages back to the sender.

- Model of Operation:
  - Fixed Source Amount ("if I send this much, how much will the receiver get?"):
  sender → sender:+ILP "crafted" packet:
                     {dst address,
  sender → connector:+TX:
                      ILP crafted packet}
  connector → receiver: ILP packet
  receiver → connector: reject
                       + amount received
                       + TX expiresAt
  connector → sender: reject
                       + amount received
                       + TX expiresAt
  sender → sender: Inspect error.ammount
  sender → sender: +ILP packet with
                    estimated fixed_src_amount
  Note: connectors recognizing the specially crafted condition MAY
  "forward" the payment without actually reserving funds, since they
  know the payment will not be executed.

  - Fixed Destination Amount:
    (Same as fixed source amount but initial TX amount is set to arbitrary probe value.
Web Monetization API
- Web Monetization browser API
- ILP micropayments to monetize a site. 
- Is Not a W3C Web Payments API
- Web Monetization makes use of Payment Pointers in order to associate a
   site with an ILP destination, and SPSP in order to set up ILP payments.
browser → web: visit page
browser ← web: html + JS
browser → JS:  run
JS      → JS: check window.monetize is defined
JS      → monetize: Promise = monetize({ receiver /*payment pointer*/ })
monetize→ UI: ask user to pay
monetize← UI: "OK"
monetize→ ??: initiate ILP payment
If confirmation of receipt is required,
the backend which provides the SPSP server can be queried.
ILP Torrent:
- Monetizing the web
"""Support the Web with a Feel-good Subscription
  With an active Coil subscription, we pay a donation to websites that you
  visit. The more time you spend on a website the more we donate."""

- @[]
  World-renowned browsing platform Mozilla has announced that it is
  prepared to proffer solutions to the glitch faced by developers in
  the Firefox Reality ecosystem with the launch of a new monetization
  platform with the support of coil.

  Mozilla opted for the Ripple-backed web payment platform because of
  the standard it offers in executing transactions. Coil ensures the
  streaming of micropayments to creators instantly with the use of an
  open API developed on Ripple’s Interledger Protocol.
Trust relationships in
Universal (non-atomic) Mode
-extracted from Michiel de Jong's comment on Gitter (Nov 02 19:46)-
Trust relationships:
sender    trusts ledger    with its balance
receiver  trusts ledger    with the payment amount
receiver  trusts connector with the opportunity cost
                           of trying a payment
                           that may fail *1
connector trusts ledgers   with its balances
connector trusts [sender, receiver, connectors]
                           with the opportunity cost
                           of trying a payment.
- 'TRUSTLESS CONNECTORS' refers to the fact that senders and receivers
  don't trust connectors with any actual value (except opportunity cost
  in case the connector fails)
Settlement vs Bilateral Ledger
│ SETTLEMENT LEDGER                              │ BILATERAL LEDGER
│ ─ "Real ledger" reflecting client balances     │ ─ "Virtual" ledger which the peers two connectors transacting
│ ─ State change when peers settle their balance │   through BTP, ILP─over─HTTP or any other ILP connector protocol
│ ─ Ussually "slow" to process ILP payments in   │ ─ When a peer keeping Authoritative State receives an ILP packet
│   real─time                                    │   it process it and adjust their copy of the bilateral ledger.
│ ─ Most of the times not ILP ready              │ ─ The Authoritative State is the  authoritative view of the
│                                                │   Bilateral Ledger's state, maintained by one or both of the peers:
│                                                │   ─ peers can get into dispute due to timeouts┼race─conditions
│                                                │   ─ When disputes are fixed a settlement into the settlement
│                                                │     ledger can be done
- HTLA stands for "Hashed Timelock Agreements"
- generalization of the idea of a Hashed Timelock Contract (HTLC) used in
  Bitcoin/Lightning Network term for conditional transfers where the
  conditions and timeouts are enforced by the ledger.
- Hashlocks and timeouts can be enforced by ledgers or they can be
  upheld by senders and recipients themselves. (In ILPv4+ a ledger is
  considered just another connector)

Technology vs Complexity vs Risk
                        Conditional        Ledger Escrow      Simple Payment    Trustlines
                        Payment Channels  (using HTLCs)           Channels
                          (with  HTLCs)
Ledger Support Required   High             High                   Medium          Low
Implementation Complexity High             Medium                 Low             Low
Bilateral Risk            Low              Low                    Medium          High
External links
 - [Video] Lightning & Payment Channels Explained
 - 1

   Lightning Overview
Error Handling
- Errors may be generated at any point as an Interledger payment is being prepared or by the receiver.

- Connectors that are notified of an outgoing transfer being rejected MUST reject the corresponding
  incoming transfer with the same error

- ILP Protocol(Errors Section)

- ilp-error-format

- ilp-error-codes

- Error ASN.1 bin.format

- Non expected errors like "division-by-zero", "null-pointers",
  "asserts to false", ... will be returned as internal errors (if
  triggered by the connector) or application errors (if triggered by
  external applications handling connectors incomming payments) - REF
1: JavaScript ILPError@ilp-packet/index.js
(non-atomic) mode

- Timeout scenario:
      sender  → connector1 → connector2 → receiver
              │            │            │ ← fulfill─ │
+10 msecs     │            │ ← fulfill─ │            │
+ 3  secs  timeout     timeout        on-time     on-time

  If the fulfillment arrives to connector2 it will execute pending on-hold
money from connector1, but since the fulfillment arrives late to connector1,
both sender and connector1 (that were waiting for up to a timeout for the
fulfillment response) will rollback. Sender gets its money back but connector1
, that was already paid to connector2, is not rewarded and looses money.

- Mail thread

- Avoiding timeouts warrants atomicity for the distributed transaction.
  Nothingless, the default mode of operation just warrants that
  "most" of the times the transaction will be atomic except for a few
  scenarios where race-condition can arise.
  Extracted from Alternative Algorithm for Timeouts
  """It's possible that at some point there is an overload in the
     destination ledger. At this point the average time to process the
     incomming transfer, executing and returning the fulfillment will
     increase approaching the initial timeout.  The closer it is to the
     timeout the more probable for race condition during the "travel
     back".""" Different solutions exists for safe (timeout-free)
     solutions, like using an external clock acting as "notary" or "judge"
     deciding deterministically when a payment timed-out or not. Also
     "very big" timeouts will suffice.

- Setting correct timeouts in essential for proper network performance.
  Using "big timeouts" will be safer but will block money in the
  escrow and decrease the liquidity We also want to minimize the risk
  or race-condition when payment is fulfilled in the receiving ledger
  but rejected on the sending ledger due to a timeout in the
  window-time when the fulfillment is returning back to the originating
  (sending) ledger.

- ref
  """... the ILP packet already has an expiry.
  It's implemented in the PSK details so the receiver knows whether the
  packet it issued is still valid. But that's an application layer concern,
  because it's only the receiver who looks at the ILP packet's expiry. The
  connectors only need to know the expiries of the local transfers..."
Atomic mode
- Standard Universal Mode introduces risks to connectors due to
  race-conditions (See topic "Tunning TIMEOUTS").
- Atomic mode warrants ACID transfers through all the ledgers BUT is not
  yet part of the standard ILP RFCs.
- Extracted from (broken link)
  """The Atomic mode outlined in the Interledger whitepaper may be
  used within segments of an Interledger payment path amongst groups of connectors
  and ledgers that support the required functionality. In an open system of
  interconnected ledgers, it seems unlikely that all parties in a payment path
  would have commonly trusted entities between them that could serve as notaries.
  The protocols used within specific groups need not be standardized because the
  failure to select commonly trusted notaries would prevent interoperability anyway"""

- Different approached exist:
  - Two-phase commit protocol
  - Threshold conditions (extension of multisignature conditions).
    from Issue #101:
    """(David Fuelling) In atomic-mode, the local-ledger transfers
       use threshold conditions (among other things) to wrap Preimage
       conditions used in the ILP packet."""
    From Crypo-condtions draft
    """Crypto-conditions elegantly support weighted multi-signatures and
     multi-level signatures.  A threshold condition has a number of
     subconditions, and a target threshold.  Each subcondition can be a
     signature or another threshold condition.  This provides flexibility
     in forming complex conditions."""
  - See (Re:) Atomic Payments thread in w3c list started by Ryan Fugger
    Extracted from Stefan Thomas reply:
    """....we haven't abandoned the ideal insofar ...
       we still want any many payments as possible to be atomic ...
       we cannot assume that atomic mode will always be available.
       ... all participants along the payment chain have to have full
       unconditional trust in the notary ... in order to be able to use
       atomic mode all of the time, there must be at least one notary that
       is trusted by all people in the world. Otherwise, we may
       run into situations where a liquidity path is available, but no valid
       notary can be selected.

       It is possible to use multiple notaries in a payment, but that actually
       doesn't make the trust problem easier and arguably makes it harder...
       then we now need all participants to trust notaries such that none
       of the notaries they trust would ever collude with any other notary they trust.

      ºIt is possible to use atomic mode in the context of a universal mode       º
      ºpayment. Any number of participants can decide to make the transfer betweenº
      ºthem subsidiary to some notary. If all the participants do that,           º
      ºcongratulations, the payment is fully atomic.                              º


       Ripple is currently building a proprietary network for banks that uses
       atomic mode internally and universal mode externally.

       ...XRP Atomic Mode Autodetection (XAMA). The idea is to allow participants in
       a payment to detect that XRP is used as one of the hops and then defer to
       the outcome of the XRP transaction instead of using their own timeouts,
       effectively making the XRP Ledger a de-facto notary.
        This can be generalized as a defer-right and defer-left behavior.
        Any neighboring pair of participants (:= sender|receiver|connector) can
       - by mutual agreement - decide to defer the outcome of their
       transfer to whatever the outcome on the ledger right of them or the ledger
       left of them.
  - and from Adrian-Hope reply:
    """In my experience to date, it's most often people familiar with existing
        payment systems that want atomic mode. I think that in time ºwe'll find thatº
       ºcomplete end to end atomicity comes at a cost that is not justified for aº
       ºlot of payments.                                                         º
       º... There are operational costs that must be covered but ... the cost to º
       ºmove the bytes from A to B to make a payment is certainly nowhere        º
       ºnear the 1% and up that most payments cost to send.                      º

       º In a world where ILP is a foundational layer ...  it's still possibleº
       ºfor someone to send a payment at almost zero cost if they accept the  º
       ºassociated risks.                                                     º

  - About New ILP architecture From Adrian Hope
     """Ledger layer components don't have to understand ILP unless they choose to
    re-use the condition for their own local transfer. Ledgers themselves
    ºneverº have to understand ILP.

      Remember a ledger layer protocol could use a completely different
    conditional payments scheme, like atomic mode ILP, where it takes the
    end-to-end condition and creates a new compound condition that depends on
    the fulfillment and some notary signature.
Software Implementations

JS stack [github]
- Framework for creating payment-channel based ILP ledger plugins,
  including a framework for attaching on-ledger settlement mechanisms.
- """Any ledger protocol author can definitely fork BTP, or
       design something completely different from scratch.
       However, as we've found writing ledger plugins, it's much easier to
       use something like the payment channel framework than implement everything
       yourself. That framework will be changed to use the BTP as the base protocol
       and allow individual plugins to add custom messages (in the same way you can
       add custom RPC methods now) and custom data to existing messages (in the same
       way you can add custom arguments to existing RPC calls now). The benefit of
       allowing for multiple plugin types is that we don't have to standardize this
       layer. But as we've seen from experience it's way easier to implement plugins
       if you can reuse something like that framework that does 80% of the work for
       you (and avoids common gotchas)"""

- From RFC PR263
- GitHub
ILP-Plugin arch?

- Early on in the project the goal was to define a standard interface for
"ledgers" which would abstract away the functions of a particular ledger and
expose the functions required of a sender, receiver or connector. Given that
the technology of choice for the majority of contributors at the time was
Javascript, this was done in Javascript and described in
IL-RFC 4 the Javascript Ledger Plugin Interface

- Subsequently a number of Javascript plugins have been developed that expose this interface including:
  - ilp-plugin-bells for the reference Five Bells Ledger (pre-ILPv4)
  - Plain account (BTP; no settlement)
  - Plain asymmetric server (BTP; no settlement)
  - (See Ripple in Blockchains section for more info about Ripple Network XRP support)t)
  - ilp-plugin-ethereum for Ethereum
       I'll work on
       this week.  Can you try using ?
       Michiel de Jong @michielbdejong Feb 26 14:43 I think I'll try to use
       Machinomy on Rinkeby instead of Ropsten, see machinomy/machinomy#160
       Amundsen now runs on
       port 1813, see - I'll
       write a client-side LPIv2 plugin for it and try out if it works! :)
       Unidirectional.sol ethereum contract for payment channels
      Michiel de Jong @michielbdejong Mar 01 11:25
      @ukstv I'm a bit stuck on sharafian/ilp-plugin-ethereum-asym-client#1 -
      we want to create the payment channel while explicitly setting
      the user's address and the peer address,
      see L53-56,
      any idea how we can do that?
      Sergey Ukustov @ukstv Mar 01 11:57 @michielbdejong There is
      one, commented on the issue.

  - Ethereum Payment Channels
  - ilp-plugin-bitcoin-paychan for Bitcoin using payment channels

  - ilp-plugin-virtual for establishing a "Virtual" ledger between two nodes
  - ilp-plugin-chain for Chain
        ilp-plugin-lightning for Bitcoin/Litecoin lightning networks
        ILP-LIGHTNING demo

  - ilp-plugin-stripe
    Receive money in your Stripe (@[]) sandbox account, using
    Amundsen, Interfaucet Michiel de Jong @michielbdejong Jan 31 14:56
    You can now receive money in your Stripe sandbox account, using
    Amundsen, Interfaucet and
    I'll temporarily put lnd on port 1801, as we wait for more ports to be opened.
    Then, I'll put 18Q1 interface for none/stripe/flutterwave on
    1810, xrp on 1811, lnd on 1812, eth on 1813.
    I'll keep Amundsen ports 1820-1829 reserved for 18Q2, etcetera.
    Adrian Hope-Bailie @adrianhopebailie 11:39
    @michielbdejong is this documented somewhere?
    Michiel de Jong @michielbdejong 13:03
    @adrianhopebailie not yet! created this:

  - BTP "TO" FROG "TO" Existing ledgers
    FROG wraps an existing connector plugin (for example
    five-bells-plugin) into a BTP connection.

    New implementations are encouraged to natively support BTP and
    can run alongside a ledger adaptor such as Frog in the BTP Toolbox
    which can load ledger plugins as required and wrap these in a BTP
Connector Shard
"As pioneered by @justmoon in the ilp-connector-shard,
 this implementation assumes that each account will be managed
 by a single process. This allows the balance to be cached and
 updated in memory and enables using fast, single-process databases
 such as LevelDB or RocksDB."
- simple, good performance, easy to set up, easy to extend/reimplement,
  robust against DoS attacks, scales to many users,
  Composable (could be run with/without UI, static routes, etc,..)
- ILP over XRP(Ripple "XRP" Network)
  Ripple Map
- JS Devel. Links
  - ilp-plugin-xrp-asym-client
  - ilp-plugin-xrp-paychan for XRP using Payment Channels
  (See also: Ripple Payment-channels tutorial using JSON-RPC API)
  - XRP Asymmetric Server/
  - ilp-plugin-xrp-escrow for XRP using XRP Escrow
Java stack
- Gitter Channel : @[]
- Quilt @[]
- specs (mandatory types/structs/...)+default impl. for ILP compliant java implementations

BºCore specº
- ILP Address      : @[]

- Runtime Exception: @[]
                     (Looks useless)
- ILP Pro.Exception: @[]

- ILP Packet       : @[]

  - SPSP
  - Stream
  - ILQP, ...

- 138 Pull request : adding BTP and ILDCP modules:

  - extending the standard ILP (sha256)preimage with advanced crypto-conditions like multisignature, threshold-signatures, ...-

interledger4j Intro

ILP hosted payments
how to use a hosted ledger to speed things up
  __ Initial setup __
  shop devel → shop:
     Add a ledger to the shop app.
     (private ledger / "trust-line")
  client     → shop: open account
  __ (stream) payment __
  client     → shop: pay letters
    to client's account at shop.ledger
   (much faster than XRP)
- The shop's ledger will expose version 1.0 of the Bilateral Transfer
  Protocol (BTP), optimization of the Ledger Plugin Interface (LPI),
  transported over a WebSocket.  These BTP packets are similar to the
  objects passed to plugin.sendTransfer or plugin.fulfillCondition,
  although they are a bit more concise, and before they go onto the
  WebSocket, they are serialized into OER buffers.
Streaming Tutorial
- """...Just use an increasing paymentId++ (And do NOT disconnect in the outgoing_fulfill handler)
  Mid-request payments:
  - To increase speed http response with a 402 status is dropped in
    the shop server (avoid client's disconnection), return 200 status,
    flush the headers, and stall the delivery of the body. The body will
    consist of the letters the client buys, and will keep streaming them
    indefinitely, until the client interrupts the connection , or the
    server process is terminated: """
  res.writeHead(200, {
    'Pay': [
         plugin.getAccount() + '.' + user,
         base64(secret) ].join(' ')
  // Flush the headers in a first TCP packet:
  res._headerSent = true

  In the client:
- res.body.pipe(process.stdout)
Connector Risk Mitigation:
- """...When you set up an IToT node, it doesn't matter which ledger you connect
   to first. Just like it doesn't matter whether you connect to the internet
   via WiFi or Ethernet or 3G. The easiest way to set up an IToT node, so far,
   is using a NodeJS script running on your laptop, in combination with an XRP
   testnet account. First, we need an Interledger payment script. Interledger
   payments are quite simple in fact, you just need to send the generate a random
   string called the fulfillment, and then send the SHA256 hash of that fulfillment
   along with your ledger-specific transfer. If you pay to yourself then you can
   easily reply to the incoming payment from the same script, using the fulfillment
   of the SHA256 condition. ..."""
  """...Evan Schwartz @ Gitter: """Connectors have a risk that their peers will not
   settle with them for the full value of payments they've sent through. The
   mitigations for that are to limit your exposure to whatever level you're
   comfortable with. If your settlement mechanism is free, like payment channel
   updates, you could keep the amount you need to trust your peers for very
- (Extracted from RFC0029-STREAMs) To avoid storing a 32 byte secret
  for each connection, a server MAY deterministically generate the
  shared secret for each connection from a single server secret and a
  nonce appended to the ILP Address given to a particular client, for
  example by using an HMAC.
Terraform Connector@github
Terraform Connector@github
- """instructions to run an Interledger connector. As the community creates
    more ways to deploy the connector, they'll be added to this repository.
    These instructions are intended for people who want to take part in the
    early Interledger network as connectors. You'll have to find other members
    of the community to peer with, and will have to maintain your connector in
    order to stay on the network.
    These instructions will not be perfect, so don't hesitate to ask for help in
    our Gitter. If you find any mistakes, please submit a PR to this repo to help
    future readers."""
- Tier 1 with XRP and AWS
- Set up your domain
- Acting as a server
- Adding another peer
- Upgrading to SSL

- Tier 2 with XRP and AWS
- Access your Connector
Home ILP router
  "Home router" for ILP payments
npm install -g moneyd
Anonymous payments
Adrian Hope-Bailie on Gitter:
"""A node that wants to allow anonymous senders to send
payments through it can simply require them to prefund
the payments. An implementation of this is available
using XRP Payment Channels"""
Chunked payments
    Evan Schwartz @ Gitter: """Chunked payments are not atomic so it is
theoretically possible that a payment could complete 80% and then you'd need
to get the receiver to send the money back. However, I think that case might be
more analogous to having all the internet cables between here and Japan cut
suddenly. It's theoretically possible, and it would definitely impact our
experience of communicating, but in practice it's not something we worry about
on a day to day basis. If a payment completes only 80% and there's absolutely
no liquidity to finish it, there's a decent chance that we have bigger problems
to worry about."""
Evan Schwartz @emschwartz Feb 28 16:09 @nathanawmk it's coming together
(see the issues titled "Phase X")
Nathan Aw @nathanawmk Feb 28 16:15 @emschwartz Thanks!!
I saw Phase 0, Phase 1, Phase 2, Phase 3. I guess we are looking at Phase 0 now?
And we are looking April as the roll out date? Is this something that I can share?
Because I am trying to get more folks interested and aware of interledger in
this part of the world -- Singapore and Hong Kong specifically.
W3C Web Payments & Interledger
""" ...Adrian Hope Bailie to ˂˃, ˂˃)
  Hi all, I have just pushed an updated Interledger Payment Method spec to WG repo.

  I have also added an explainer which you can see on the GitHub repo:

- The spec is here:
  Welcome any feedback!
  Given that Chrome have now publicly announced their intent to ship Payment
  Handler we (the Interledger community) are looking for any Payment Handler
  implementers interested in adding support for Interledger.
- Bill&Melinda Gates Foundation project
- implements Interledger at its core.

Adrian Hope blog Entry

GitHub code at Mojaloop
SPSP Server
Dora-GT questions
dora-gt Is there any material to refer about amount control, like...
- if I want to send $10 by XRP, how to control destination amount?
- if I want the receiver to receive just $10. How to make it accurate in the higher layer without using ILQP.

Evan Schwartz @emschwartz Feb 04 19:22 @dora-gt great question.
That type of functionality is now in the transport layer, rather than the Interledger layer:
- If you want to specify a minimum that the receiver should accept for a certain packet,
  that can be included in the ILP Prepare data as is done in PSK2
  ( )
- If you want to determine the path exchange rate you can send an unfulfillable test payment and
   ask the receiver how much arrived, also done in PSK2
  ( ).

- The two major changes with ILPv4:
  - some of the fields moved from  Ledger Layer's transfer object UP to the ILP packet (Interledger layer)

  - some of the functionality that was in the Interledger layer was moved into the transport layer.

  We realized that you could get the same benefits from ILQP and having the fixed destination amount
  in the ILP packet without needing all of the connectors and the core of the network
  to have special functionality for that

The changes I do think affect functionality when seen from the outside, are:

Payment Changes for ILPv4:
 │Dropped                  │ Replaced by  │ Advantage           │
 │fixed─destination─amount │ best─effort  │ no more need for    │
 │                         │              │ price─based routing │
 │ multi─dollar            │ sub─dollar   │ no more need for    │
 │                         │              │ on─ledger escrow    │
RFC29 Stream (Trans.Pro)

Bº5.1.1. Encryption Envelopeº
       Field               Type           Description
       Random IV           12-Byte UInt   Nonce used as input to the AES-GCM algorithm.
                                          Also ensures conditions are random.
                                          Endpoints MUST NOT encrypt two packets with
                                          the same nonce
       Authentication Tag  16-Byte UInt   Authentication tag produced by AES-GCM encryption
                                          that ensures data integrity
       Ciphertext          0-32739 Byte   Encrypted data (see below for contents)

Note that the Ciphertext is NOT length-prefixed. The length can be 
inferred from the ILP packet because the whole data field is encoded 
with a length prefix. (This is done so that the entire data field is 
indistinguishable from random bytes.)

Bº5.1.2. Encryption Pseudocodeº
  The encryption key used for every packet sent for a given connection 
  is the HMAC-SHA256 digest of the shared secret and the string 
  "ilp_stream_encryption", encoded as UTF-8 or ASCII (the byte 
  representation is the same with both encodings).
    var iv = random_bytes(12);
    var encryption_key = hmac_sha256(shared_secret, "ilp_stream_encryption");
    var { ciphertext, auth_tag } = aes_256_gcm(encryption_key, iv, data);

Bº5.1.3. Maximum Number of Packets Per Connectionº
  Implementations MUST close the connection once either endpoint has 
  sent 2^31 packets. According to NIST, it is unsafe to use AES-GCM for 
  more than 2^32 packets using the same encryption key. (STREAM uses 
  the limit of 2^31 because both endpoints encrypt packets with the 
  same key.)

Bº5.2. STREAM Packetº
  See the ASN.1 definition for the formal packet specification.
  Field           Type        Description
  Version         UInt8       1 for this version
  ILP Packet Type UInt8       ILPv4 packet type this STREAM packet MUST be sent in (12 for Prepare, 13 for Fulfill, and 14 for Reject). Endpoints MUST discard STREAM packets that comes in on the wrong ILP Packet Type. (This is done to prevent malicious intermediaries from swapping the data fields from different valid ILP packets.)
  Sequence        VarUInt     Identifier for an ILP request / response. Clients and Servers track 
                              their own outgoing packet sequence numbers and increment the Sequence 
                              for each ILP Prepare they send. The Receiver MUST respond with a 
                              STREAM packet that includes the same Sequence as the Sender's Prepare 
                              packet. A sender MUST discard a STREAM packet in which the Sequence 
                              does not match the STREAM packet sent with their ILP Prepare.
  Prepare Amount  VarUInt     If the STREAM packet is sent on an ILP Prepare, this represents the 
                              minimum the receiver should accept. If the packet is sent on an ILP 
                              Fulfill or Reject, this represents the amount that the receiver got 
                              in the Prepare.
  Frames         SEQUENCE OF  An array of Frames, which are specified below.
  Junk Data      N/A          Extra bytes that MUST be ignored. Implementations MAY append 
                              zero-bytes to pad packets to a specific size. Future versions of 
                              STREAM may specify additional fields that come after the Frames 
                              (zero-bytes MUST be used for padding to avoid confusion with future 
                              protocol versions).
Bº5.3. Framesº
  See the ASN.1 definition for the formal specification of the frame 
  encoding and each frame type.

  Each frame is encoded with its 1-byte type and length prefix. 
  Implementations MUST ignore frames with unknown types. Future 
  versions of STREAM may add new frame types.

  Field   Type         Description
┌ Type    UInt8        Identifier for the frame type (see below)
· Data    Var-Length   Frame contents
·         Octet String
└ Type ID   Frame
  0x01      Connection Close              0x10      Stream Close
  0x02      Connection New Address        0x11      Stream Money
  0x03      Connection Max Data           0x12      Stream Money Max
  0x04      Connection Data Blocked       0x13      Stream Money Blocked
  0x05      Connection Max Stream ID      0x14      Stream Data
  0x06      Connection Stream ID Blocked  0x15      Stream Data Max
                                          0x16      Stream Data Blocked
Bº5.3.1. ConnectionClose Frameº
  Field         Type        Description
  Error Code    UInt8       Machine-readable Error Code indicating why the connection was closed.
  Error Message Utf8String  Human-readable string intended to give more information helpful for 
                            debugging purposes.

  - If implementations allow half-open connections, an endpoint MAY 
  continue sending packets after receiving a ConnectionClose frame. 
  Otherwise, the endpoint MUST close the connection immediately.

Bº5.3.2. ConnectionNewAddress Frameº
  Field   Type         Description
  Source  ILP Address  New ILP address of the endpoint that sent the frame.

Bº5.3.3. ConnectionMaxData Frameº
  Field        Type         Description
  Max Offset   VarUInt     The total number of bytes the endpoint is willing to receive on this connection.

  Endpoints MUST NOT exceed the total number of bytes the other endpoint is willing to accept.

Bº5.3.4. ConnectionDataBlocked Frameº
  Field        Type         Description
  Max Offset   VarUInt     The total number of bytes the endpoint wants to send.

Bº5.3.5. ConnectionMaxStreamId Frameº
  Field        Type         Description
  Max Stream ID   VarUInt     The maximum stream ID the endpoint is willing to accept.

Bº5.3.6. ConnectionStreamIdBlocked Frameº
  Field        Type         Description
  Max Stream ID   VarUInt     The maximum stream ID the endpoint wishes to open.

Bº5.3.7. StreamClose Frameº
  Field        Type         Description
  Stream ID    VarUInt     Identifier of the stream this frame refers to.
  Error Code   UInt8       Machine-readable Error Code indicating why the stream was closed.
  Error MessageUtf8String  Human-readable string intended to give more information 
                           helpful for debugging purposes.

If implementations allow half-open streams, an endpoint MAY continue 
sending money or data for this stream after receiving a StreamClose 
frame. Otherwise, the endpoint MUST close the stream immediately.

Bº5.3.8. StreamMoney Frameº
  Field        Type         Description
  Stream ID    VarUInt      Identifier of the stream this frame refers to.
  Shares       VarUInt      Proportion of the ILP Prepare amount destined for the stream specified.
  The amount of money that should go to each stream is calculated by 
  dividing the number of shares for the given stream by the total 
  number of shares in all of the StreamMoney frames in the packet.
  For example, if an ILP Prepare packet has an amount of 100 and three 
  StreamMoney frames with 5, 15, and 30 shares for streams 2, 4, and 6, 
  respectively, that would indicate that stream 2 should get 10 units, 
  stream 4 gets 30 units, and stream 6 gets 60 units.

  If the Prepare amount is not divisible by the total number of shares, 
  implementations SHOULD round the stream amounts down. The remainder 
  SHOULD be allocated to the lowest-numbered open stream that has not 
  reached its maximum receive amount.

Bº5.3.9. StreamMaxMoney Frameº
  Field        Type         Description
  Stream ID    VarUInt     Identifier of the stream this frame refers to.
  Receive Max  VarUInt     Total amount, denominated in the units of the endpoint sending this 
                           frame, that the endpoint is willing to receive on this stream.
  Total        VarUInt     Total amount, denominated in the units of the endpoint sending this 
  Received                 frame, that the endpoint has received thus far.
  The amounts in this frame are denominated in the units of the 
  endpoint sending the frame, so the other endpoint must use their 
  calculated exchange rate to determine how much more they can send for 
  this stream.

Bº5.3.10. StreamMoneyBlocked Frameº
  Field        Type         Description
  Stream ID    VarUInt      Identifier of the stream this frame refers to.
  Send Max     VarUInt      Total amount, denominated in the units of the endpoint sending this 
                            frame, that the endpoint wants to send.
  Total Sent  VarUInt       Total amount, denominated in the units of the endpoint sending this 
                            frame, that the endpoint has sent already.

Bº5.3.11. StreamData Frameº
  Field        Type          Description
  Stream ID   VarUInt        Identifier of the stream this frame refers to.
  Offset      VarUInt        Position of this data in the byte stream.
  Data        VarOctetString Application data.

  Packets may be received out of order so the Offset is used to 
  indicate the correct position of the byte segment in the overall 
  stream. The first StreamData frame sent for a given stream MUST start 
  with an Offset of zero.

Bº5.3.12. StreamMaxData Frameº
  Field        Type          Description
  Stream ID   VarUInt        Identifier of the stream this frame refers to.
  Max Offset  VarUInt        The total number of bytes the endpoint is willing to receive on this stream.

Bº5.3.13. StreamDataBlocked Frameº
  Field        Type          Description
  Stream ID   VarUInt        Identifier of the stream this frame refers to.
  Max Offset  VarUInt        The total number of bytes the endpoint wants to send on this stream.

Bº5.4. Error Codesº
  Error codes are sent in StreamClose and ConnectionClose frames to 
  indicate what caused the stream or connection to be closed.

  Error Code  Name                Description
  0x01        NoError             Indicates the stream or connection closed normally.
  0x02        InternalError       The endpoint encountered an unexpected error.
  0x03        EndpointBusy        The endpoint is temporarily overloaded and unable to process the packet.
  0x04        FlowControlError    The other endpoint exceeded the flow control limits advertised.
  0x05        StreamIdError       The other endpoint opened more streams than allowed.
  0x06        StreamStateError    The other endpoint sent frames for a stream that is already closed.
  0x07        FrameFormatError    The other endpoint sent a frame with invalid syntax.
  0x08        ProtocolViolation   The other endpoint sent invalid data or otherwise violated the protocol.
  0x09        ApplicationError    The application using STREAM closed the stream or connection with an 

  There are two methods the sender can use to generate the condition, 
  depending on whether they want the payment to be fulfillable or not.

Bº6.1. Unfulfillable Conditionº
  If the sender does not want the receiver to be able to fulfill the 
  payment (as for an informational quote), they can generate an 
  unfulfillable random condition.

  var condition = random_bytes(32);

Bº6.2. Fulfillable Conditionº
  If the sender does want the receiver to be able to fulfill the 
  condition, the condition MUST be generated in the following manner.
  The shared_secret is the cryptographic seed exchanged during Setup. 
  The string "ilp_stream_fulfillment" is encoded as UTF-8 or ASCII (the 
  byte representation is the same with both encodings). The data is the 
  encrypted STREAM packet.

  var hmac_key = hmac_sha256(shared_secret, "ilp_stream_fulfillment");
  var fulfillment = hmac_sha256(hmac_key, data);
  var condition = sha256(fulfillment);

Bº6.3. Fulfillment Generationº

  The following pseudocode details how the receiver regenerates the 
  fulfillment from the data.

  The shared_secret is the cryptographic seed exchanged during Setup. 
  The string "ilp_stream_fulfillment" is encoded as UTF-8 or ASCII (the 
  byte representation is the same with both encodings). The data is the 
  encrypted STREAM packet.

  var hmac_key = hmac_sha256(shared_secret, "ilp_stream_fulfillment");
  var fulfillment = hmac_sha256(hmac_key, data);

BºAppendix A: Similarities and Differences with QUICº
  Unlike QUIC, STREAM:
  - Has only one packet header instead of QUIC's short and long 
  - Uses the shared secret to identify the Connection rather than 
    having a separate Connection ID.
  - Does not include a cryptographic handshake, because STREAM 
    assumes a symmetric secret is communicated out of band.
  - Does not support unidirectional frames. The QUIC community had 
    significant debate over whether to include unidirectional streams, 
    bidirectional streams, or both. They settled on both primarily to 
    support the HTTP request/response pattern as well as HTTP/2 Server 
    Push. Unidirectional streams were left out of STREAM because they add 
    complexity and are a premature optimization for this protocol now.
  - Does not have ACK frames, because ILP Prepare packets must be 
    acknowledged with either a Fulfill or Reject packet. If the response 
    includes an (authenticated) STREAM packet, the sender can treat that 
    as an acknowledgement of the control and data frames from the Prepare 
    packet they sent.
  - Does not have Ping, Path Challenge, or Path Challenge Response 
    frames, because a STREAM packet with no frames can be used instead. 
    As long as the Client and Server increment the packet sequence for 
    each packet they send, a valid Fulfill or Reject packet from the 
    Receiver that includes the correct sequence in the encrypted data 
    serves as the path challenge and response.
ILDCP,PING protocols
Adrian Hope @ interledger/Lobby chat:
If anyone is interested in contributing to this work and helping to 
make it easy for others to provide alternative implementations we 
have some spec debt which we need to repay and these would be great 
first issues to tackle.

Closed (Stale) issue: Documenting the PING protocol:

The ILDCP, PING and routing protocols are all implemented in
See also ildcp-host.ts @
but not yet documented as RFCs
Test Vectors
- Test vectors contains a set of fulfillment and conditions that any
  compliant implementation must pass.
- Only preimage is used right now
- ILDCP stands for: Interledger Dynamic Configuration Protocol
By Michael B. de  Jong ("ex ILPer")
"like a crypto-currency, but better!"
· Monday: Transitivity of Trust
· Tuesday: Commodity Money
   Having learned from their first experiment, on Tuesday, the 
  merchants try out a different system. They realize that each of them 
  likes gold, and gold is scarce. They decide to use gold as a 
  commodity currency. Each merchant offers the item they have for sale 
  to their counter-clockwise neighbor in exchange for a grain of gold.
· Wednesday: Fiat Money
· Thursday: The Banker's Ledger
· Friday: Ledger Federation
· Saturday: Crypto-currencies
· Sunday: LedgerLoops
  On the seventh day, one of the merchants invents LedgerLoops. What he 
  does is actually quite simple: Bºhe tells his counter-clockwise º
Bºneighbor: I will give you this item, but only if you can show me the   º
Bºsolution of this hashlock. This hashlock is a cryptographic challenge  º
Bºwhich he knows only he can solve, but for which anyone could verify    º
Bºand agree whether a given solution is correct. Each merchant tells     º
Bºhis counter-clockwise neighbor the same, until the initiator's own     º
Bºclockwise neighbor does so. Now that the initiator of the hashlocked   º
Bºloop has a promise from his clockwise neighbor, mentioning the         º
Bºhashlock he himself created, he can safely solve the hashlock and      º
Bºpublish the solution. After this, the correct solution is sent back    º
Bºin the other direction, and all trades are completed.                  º

· Conceptually, LedgerLoops as a technology sits somewhere inbetween 
  blockchain and LETS systems. Its use of multilateral netting is 
  similar to Ripple Classic and Trustlines Network, and its use of 
  hashlocks is similar to Bitcoin Lightning and Interledger.

· Unlike crypto-currencies, the LedgerLoops network does not facilitate 
  payment. Instead, it aims to facilitate trade through multi-lateral 
  barter rather than monetary payment. The hashlock solution that is 
  passed around acts as a cryptographic trigger for trade, not as an 
  asset that represents value. LedgerLoops is a communication mechanism 
  that allows trade partners to enter into agreements with each other, 
  conditionally on similar agreements being negotiated synchronously. 
  Trade is facilitated without money is being transmitted, so users of 
  LedgerLoops would arguably not need a money transmitter license. That 
  said, you should always check and comply with the legal situation in 
  your own country, and in any case, the trades that are coordinated 
  using LedgerLoops would still be subject to value-added tax and 
  income tax for the participants, like any other trades.
ILP Rust Implementations
RºWARN: No new activities since 2020-02

See diagram @:

Sources of Risk
What are the sources of risks:
  (asset can be source or destination unless otherwise specified)
- payer/payee asset has a fast varying random price through time compared to payee/payer asset.
  Even if the TX executes in millisecs we can not be sure that the applied (probably cached) exchange is correct.

- payer/payee asset has a fast varying increasing price through time compared to payee/payer asset.

- An asset must be physically transported. For example senders pays in dollars, receivers recieves gold.
  The gold will take time to arrive.

- The asset associated-ledger balance (public status) is false.
  The connector can loose money. The risk is bigger the "less-trustable" is the ledger.
  "less-trustable" means in practice "small" and not "back-supported".
Routing protocol
Implemented in JS version: (Not part of RFCs anymore)
Mono-repo for modular ILP connector implemented in TypeScript.

Read about it in:

RºWARNº: No commits since 2019-08

· 1. Isolate the router.
· 2. Make things modular
· 3. Support dynamic configuration
· 4. A better way to peer
   BºI’ve never been a huge fan of the plugin system but the reality is,   º
   Bºit has worked pretty damn well until now. The real challenge is that  º
   Bºas the network and some operators scale we have started to see a need º
   Bºto manage business operations like settlement (a primary function of  º
   Bºplugins) separately from packet processing (something the the         º
   Bºtraditional payments industry consider old-hat).                      º
   Bº                                                                      º
   BºSettlement is a business function that needs to sit far away from the º
   Bºpayment processing pipeline but this doesn’t mean it can’t be         º
   Bºfast and keep the settlement risk close to zero. The proposals and    º
   Bºexperiments I presented over the last few months looking at potential º
   Bºnew bilateral protocols were all done to explore ways to achieve that º
   Bºseparation.                                                           º
   Bº                                                                      º
   BºIn an ideal architecture connectors establish a very simple channel   º
   Bºwith their peers over which they exchange nothing but ILP packets.    º
   BºThese may contain messages related to settlement but it should also   º
   Bºbe possible for settlement to be handled entirely outside the scope   º
   Bºof the connector.                                                     º

- KISS java connector implementing basic ILPv4 functionallities
  Built on VertX framework ("NodeJS-like" async behaviour) can be used as 
  an skeleton for a full-featured micro-service based implementation.
- Currently supports plugins for Ethereum ethers (not ERC20 tokens)
  and ILP-over HTTP (allowing to integrate with the rest of the
  Network) as well as plugin for mock/prototype-ledgers for pedagogical

- Current status: Skeleton. plugin support for ILP-over-HTTP, 
                  Ether ledger, mocked local ledger, 
Q: What's the connection liquidity?
Ben Sharafian @sharafian Jul 18 21:03 The ethereum address is just a 
settlement detail, but doesn't say anything about the actual network 
topology. You could have multiple peering relationships using the 
same ethereum account but with different Interledger addresses, or 
you could theoretically have a link that you settle with multiple 
different addresses. Interledger is a network that exists on top of 
settlement infrastructure so we don't try to make any 1:1 mapping 
from the settlement network to the interledger network
"Jquery" to manage monetization on the Web.

Webfunding.js is a tree-shakable library to manage monetization on 
the web. It will include common solutions for cookie-aware ads, 
cookie prompt, some components to integrate print-on-demand 
merchandise, and last but not least, the new and shiny Web 
Monetization API.
ilp iroha settlement
RFC-compliant Interledger settlement engine for Hyperledger Iroha