### Initiate Payment via HTTP GET Request

Source: https://github.com/interledger/rfcs/blob/main/0026-payment-pointers/0026-payment-pointers.md

This example demonstrates how a sending client should initiate a payment by making an HTTP GET request to the resolved receiver endpoint URL. It includes essential headers like 'Host' and 'Accept' to specify supported protocols.

```http
GET /.well-known/pay HTTP/1.1
Host: bob.example.com
Accept: application/spsp+json, application/otherprotocolformat
```

--------------------------------

### SPSP Server Response Body Example

Source: https://github.com/interledger/rfcs/blob/main/0009-simple-payment-setup-protocol/0009-simple-payment-setup-protocol.md

An example of a successful SPSP server response body, containing account details required for setting up Interledger payments via STREAM. It includes the destination account's ILP address and a base64 encoded shared secret for secure communication.

```json
{
  "destination_account": "[ILP Address]",
  "shared_secret": "[base64 encoded shared secret]",
  "receipts_enabled": true
}
```

--------------------------------

### Query SPSP Endpoint

Source: https://github.com/interledger/rfcs/blob/main/0009-simple-payment-setup-protocol/0009-simple-payment-setup-protocol.md

This snippet shows how an SPSP client queries an SPSP endpoint using an HTTP GET request. It includes the necessary Host header and Accept header to specify the desired SPSP data format.

```http
GET /.well-known/pay HTTP/1.1
Host: example.com
Accept: application/spsp4+json, application/spsp+json
```

--------------------------------

### HTTP Response for STREAM Receipts

Source: https://github.com/interledger/rfcs/blob/main/0009-simple-payment-setup-protocol/0009-simple-payment-setup-protocol.md

An example of an HTTP response indicating successful STREAM receipt processing. It includes the destination account, shared secret, and a flag for receipt enablement.

```http
HTTP/1.1 200 OK
Content-Type: application/spsp4+json

{
  "destination_account": "example.ilpdemo.red.bob",
  "shared_secret": "6jR5iNIVRvqeasJeCty6C+YB5X9FhSOUPCL/5nha5Vs=",
  "receipts_enabled": true
}
```

--------------------------------

### Example Asset Scale for Amount Handling

Source: https://github.com/interledger/rfcs/blob/main/0031-dynamic-configuration-protocol/0031-dynamic-configuration-protocol.md

This example illustrates an asset scale, like '6', which defines the precision or number of decimal places for amounts used in ILP packets exchanged between nodes. This ensures consistent handling of monetary values.

```plaintext
6
```

--------------------------------

### Binary Encoding Examples for ILP Addresses

Source: https://github.com/interledger/rfcs/blob/main/0030-notes-on-oer-encoding/0030-notes-on-oer-encoding.md

Illustrates the binary encoding of ILP addresses, presenting the hexadecimal representation of the address string and its decoded value.

```Hexadecimal
186578616D706C652E746F702E6D6964646C652E6C6F776572
```

```Hexadecimal
81826578616D706C652E766572792E6C6F6E672E616464726573732E746F2E6578636565642E3132372E636861726163746572732E616E642E747269676765722E612E6C6F6E672E666F726D2E6C656E6774682E64657465726D696E616E742E746F2E73686F772E686F772E746861742E776F726B732E67726561742E61732E77656C6C
```

--------------------------------

### Payment Pointer Syntax Example

Source: https://github.com/interledger/rfcs/blob/main/0026-payment-pointers/0026-payment-pointers.md

Illustrates the basic syntax of a Payment Pointer, which consists of a '$' symbol followed by a host and an optional path.

```ABNF
"$" host path-abempty
```

--------------------------------

### SPSP Server Error Response: Invalid Receiver

Source: https://github.com/interledger/rfcs/blob/main/0009-simple-payment-setup-protocol/0009-simple-payment-setup-protocol.md

An example of an HTTP error response from an SPSP server when the specified receiver does not exist. This response includes a 404 Not Found status and a JSON body indicating the 'InvalidReceiverError'.

```http
HTTP/1.1 404 Not Found
Content-Type: application/spsp4+json

{
  "id": "InvalidReceiverError",
  "message": "Invalid receiver ID"
}
```

--------------------------------

### SPSP MIME Type Example

Source: https://github.com/interledger/rfcs/blob/main/0026-payment-pointers/0026-payment-pointers.md

Specifies the Multipurpose Internet Mail Extensions (MIME) type used for the Simple Payment Setup Protocol (SPSP), which is application/spsp+json.

```HTTP
application/spsp+json
```

--------------------------------

### Binary Encoding Examples for Timestamps

Source: https://github.com/interledger/rfcs/blob/main/0030-notes-on-oer-encoding/0030-notes-on-oer-encoding.md

Provides examples of how timestamps are encoded in binary as variable-length strings, showing the hexadecimal representation of the encoded date string and its decoded value.

```Hexadecimal
1332303137313232343136313433322E3237395A
```

```Hexadecimal
1132303137313232343136313433322E325A
```

```Hexadecimal
0F3230313731323235303030303030305A
```

--------------------------------

### Example Asset Code for Settlement

Source: https://github.com/interledger/rfcs/blob/main/0031-dynamic-configuration-protocol/0031-dynamic-configuration-protocol.md

This example shows an asset code, such as 'XRP', which specifies the currency or asset that two Interledger nodes will use for settling transfers between them.

```plaintext
XRP
```

--------------------------------

### ILP Timestamp Binary Encoding Examples

Source: https://github.com/interledger/rfcs/blob/main/0030-notes-on-oer-encoding/0030-notes-on-oer-encoding.md

Provides examples of how ILP timestamps, after being encoded into the fixed-length string format, are represented in binary using hexadecimal notation. This shows the byte-level representation of the timestamp strings.

```text
Encoding | Decoded value
| :--- | :---
| `32303137 31323234 31363134 33323237 39` | `20171224161432279`
| `32303137 31323234 31363134 33323230 30` | `20171224161432200`
| `32303137 31323235 30303030 30303030 30` | `20171225000000000`
```

--------------------------------

### Publishing Candidate Specification - RFC Front-Matter

Source: https://github.com/interledger/rfcs/blob/main/CONTRIBUTING.md

Example of front-matter for a Candidate Specification RFC, indicating its type and final draft status.

```markdown
---
title: The Interledger Architecture
type: candidate-specification
draft: FINAL
---
# Interledger Architecture

Lorum Ipsum etc
```

--------------------------------

### Example ILP Address for Child Node

Source: https://github.com/interledger/rfcs/blob/main/0031-dynamic-configuration-protocol/0031-dynamic-configuration-protocol.md

This example demonstrates a typical ILP address format that a parent node might allocate to a child node. ILP addresses are hierarchical and used for routing within the Interledger network.

```plaintext
g.crypto.foo.bar
```

--------------------------------

### Example Global Allocation Scheme Addresses

Source: https://github.com/interledger/rfcs/blob/main/0015-ilp-addresses/0015-ilp-addresses.md

Illustrates Interledger addresses using the global allocation scheme, showing destination addresses for accounts and specific invoices, breaking down components like neighborhoods, account identifiers, and interactions.

```plaintext
g.acme.bob
```

```plaintext
g.us-fed.ach.0.acmebank.swx0a0.acmecorp.sales.199.~ipr.cdfa5e16-e759-4ba3-88f6-8b9dc83c1868.2
```

--------------------------------

### Interledger Address Example

Source: https://github.com/interledger/rfcs/blob/main/0019-glossary/0019-glossary.md

Illustrates the format of Interledger addresses, which are ledger-agnostic and dot-separated strings used for addressing ledgers and accounts. These addresses help in routing payments across different ledgers.

```text
g.us.acmebank.acmecorp.sales.199
g.crypto.bitcoin.1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2
```

--------------------------------

### SIMPLE Authentication Profile Example

Source: https://github.com/interledger/rfcs/blob/main/proposals/0000-http-auth-profiles.md

Demonstrates the structure of a SIMPLE authentication token used in an HTTP Authorization header. This token is opaque to the token-bearer but contains information for the token-producer.

```HTTP
Authorization: Bearer user1234:HEiMCp0FoAC903QHueY89gAWJHo/izaBnJU8/58rlSI=
```

--------------------------------

### Simple Payment Setup Protocol (SPSP) Specification

Source: https://github.com/interledger/rfcs/blob/main/README.md

A basic Application Layer protocol that leverages HTTPS to exchange the necessary details for setting up an Interledger payment.

```Markdown
- **[9: Simple Payment Setup Protocol (SPSP)](0009-simple-payment-setup-protocol/0009-simple-payment-setup-protocol.md)**

  A basic Application Layer protocol that uses HTTPS to exchange details needed to set up an Interledger payment.
```

--------------------------------

### Interledger STREAM Connection Setup

Source: https://github.com/interledger/rfcs/blob/main/0029-stream/0029-stream.md

During connection setup, a server must provide a client with specific values over an authenticated, encrypted channel. Key exchange is not handled by STREAM. The server may also provide a pre-shared Receipt Secret and Nonce, potentially derived deterministically from the ILP Address.

```Interledger
A server MUST communicate the following values to a client using an **authenticated, encrypted** communication channel (such as 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 RECOMMENDED to use 32 bytes)

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.

For each new connection, a server MAY be provided with a pre-shared 32 byte Receipt Secret (to generate [STREAM receipts](../0039-stream-receipts/0039-stream-receipts.md)) and a 16 byte Receipt Nonce (to include in those receipts). To avoid storing this data for each connection, a Server MAY deterministically append this data to the ILP Address used for a Connection. If doing so, the server MUST encrypt the Receipt Secret.
```

--------------------------------

### Bitcoin CLTV Channels Example

Source: https://github.com/interledger/rfcs/blob/main/0022-hashed-timelock-agreements/0022-hashed-timelock-agreements.md

An example of using CheckLockTimeVerify (CLTV) for payment channels in Bitcoin, a feature enabling conditional transfers with time locks.

```mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
```

--------------------------------

### Interledger Address Examples

Source: https://github.com/interledger/rfcs/blob/main/0001-interledger-architecture/0001-interledger-architecture.md

Illustrates the hierarchical, dot-separated format of Interledger addresses used for routing. These addresses identify senders, receivers, and connectors within the Interledger network.

```plaintext
g.us.acmebank.acmecorp.sales.199
g.crypto.bitcoin.1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2
```

--------------------------------

### JWT_HS_256 Authentication Profile Example

Source: https://github.com/interledger/rfcs/blob/main/proposals/0000-http-auth-profiles.md

Illustrates an example JWT token used in an HTTP Authorization header with the Bearer scheme. This token is signed using HS256 and includes 'sub' and 'exp' claims.

```HTTP
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhbGljZSIsImV4cCI6MTU1ODAzNTg2OH0.__9CiSGdn4Grhl48slun7Lp4q4xt0uq398omcipBU8M
```

--------------------------------

### Encode/Decode Variable-length Timestamps (BTP)

Source: https://github.com/interledger/rfcs/blob/main/0030-notes-on-oer-encoding/0030-notes-on-oer-encoding.md

Details the process of encoding and decoding timestamps according to a shortened, restricted variant of ISO 8601 for use in BTP. It specifies rules for removing separators, handling UTC, precision, decimal separators, leap seconds, and midnight representation. Includes examples of valid and invalid encodings.

```Text
Encoding ISO 8601 timestamps involves removing hyphens, colons, and 'T', ensuring the date ends in 'Z' (UTC), and allowing up to millisecond precision with '.' as the decimal separator. Years must be four digits, and months, days, hours, minutes, and seconds must be two digits. Midnight is '000000' on the following day, and leap seconds use '60'. Trailing zeros in milliseconds are omitted.

Examples:
`2017-12-24T16:14:32.279112Z` -> `20171224161432.279Z`
`2016-12-31T23.59.60.852Z` -> `20161231235960.852Z` (leap second)
`2017-12-24T24:00:00.000Z` -> `20171225000000Z` (midnight)
`2017-12-24T16:14:32,182Z` -> `20171224161432.182Z` (decimal separator)
`2017-12-24T18:14:32.000+0200` -> `20171224161432Z` (UTC conversion)

Decoding requires all fields to be present and rejects extra elements. Midnight is '000000'. Leap seconds are permitted.

Invalid examples:
`20171224235312.431+0200` (not UTC)
`20171224215312.4318Z` (too much precision)
`20171224230000.Z` (spurious decimal point)
`20171224240000Z` (wrong midnight)

Valid decoding examples:
`20171224161432.279Z` -> `2017-12-24T16:14:32.279Z`
`20171224161432Z` -> `2017-12-24T16:14:32.000Z`
`20161231235960.852Z` -> `2016-12-31T23:59:60.852Z` (leap second)
`20171225000000Z` -> `2017-12-25T00:00:00.000Z` (midnight)
```

--------------------------------

### Handling Errata in Candidate Specification RFCs

Source: https://github.com/interledger/rfcs/blob/main/CONTRIBUTING.md

Example of front-matter for a Candidate Specification RFC that has errata, showing the 'errata' field.

```markdown
---
title: The Interledger Architecture
type: candidate-specification
draft: FINAL
errata: 1
---
# Interledger Architecture

Lorum Ipsum etc
```

--------------------------------

### Interledger Fixed-Length Unsigned Integers

Source: https://github.com/interledger/rfcs/blob/main/0030-notes-on-oer-encoding/0030-notes-on-oer-encoding.md

Defines the representation of fixed-length unsigned integers in Interledger, including their size, range, and big-endian encoding. Examples for UInt8, UInt16, UInt32, UInt64, UInt256, and UInt512 are provided.

```text
Type | Size | Range
:--- | :--- | :--- 
UInt8 | 1 byte | 0 .. 255 (2^8 - 1)
UInt16 | 2 bytes | 0 .. 65535 (2^16 - 1)
UInt32 | 4 bytes | 0 .. 4294967295 (2^32 - 1)
UInt64 | 8 bytes | 0 .. 18446744073709551615 (2^64 - 1)
UInt128 | 16 bytes | 0 .. 2^128 - 1
UInt160 | 20 bytes | 0 .. 2^160 - 1
UInt192 | 24 bytes | 0 .. 2^192 - 1
UInt224 | 28 bytes | 0 .. 2^224 - 1
UInt256 | 32 bytes | 0 .. 2^256 - 1
UInt384 | 48 bytes | 0 .. 2^384 - 1
UInt512 | 64 bytes | 0 .. 2^512 - 1
```

--------------------------------

### Example Public Key for JWT Verification (SSH RSA)

Source: https://github.com/interledger/rfcs/blob/main/proposals/0000-http-auth-profiles.md

An example of an SSH RSA public key used to verify JWTs signed with RS256. This key can be advertised at a TLS-encrypted HTTP endpoint.

```SSH
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC0H891JhR+Stgx81JyZeU48F4VUAS7E/OKvaVG5OjE9c+iIp2WcYFHqWjeBfrcPS1ADnTbxiKDd5D7EGWLDkBGha9H7m2hH/4PhywHomltp4Z1W7HJISzIS5JvPWFctKeKmhEekMi24yhtf44NkZg2zQijzLMQuxfaPGoW/88omtuDVaqQUmt3/Vx3v8D5ejQ2N8p7BrvpiUPQy+ZakAJf7MG0+EnaCjgnGAc9Q9wEBgMq6ifAENLne6BtQvA34jiWEIGDuD/veUwe0r0Ao/ZipZfcRJKybYNHbs5YQoxXOI2qo8qPwFrF2AJzak8+MwaiFYrDzGk8nV3e3i38RH0p test@example.com
```

--------------------------------

### Interledger Fixed-Length Signed Integers

Source: https://github.com/interledger/rfcs/blob/main/0030-notes-on-oer-encoding/0030-notes-on-oer-encoding.md

Details the encoding of fixed-length signed integers in Interledger, using big-endian and two's complement representation. Examples for Int8, Int16, Int32, and Int64 are shown with their byte representations and decoded values.

```text
Type | Size | Range
:--- | :--- | :--- 
Int8 | 1 byte | -128 .. 127
Int16 | 2 bytes | -32768 .. 32767
Int32 | 4 bytes | -2147483648 .. 2147483647
Int64 | 8 bytes | -9223372036854775808 .. 9223372036854775807
```

--------------------------------

### Virtual ILP Plugin

Source: https://github.com/interledger/rfcs/blob/main/0022-hashed-timelock-agreements/0022-hashed-timelock-agreements.md

An example of a virtual Interledger plugin that can be used to implement trustlines, allowing connections on ledgers without native Interledger support.

```JavaScript
https://github.com/interledgerjs/ilp-plugin-virtual
```

--------------------------------

### HTTP POST /accounts Request

Source: https://github.com/interledger/rfcs/blob/main/0038-settlement-engines/0038-settlement-engines.md

Sets up a new account with the settlement engine. This request informs the engine about a new account, allowing it to perform prerequisite tasks like exchanging ledger identifiers or negotiating fees.

```http
POST /accounts HTTP/1.1
Content-Type: application/json

{
  "id": "<id>"
}
```

--------------------------------

### Interledger Architecture Overview

Source: https://github.com/interledger/rfcs/blob/main/README.md

Provides a high-level overview of the Interledger architecture, outlining its components and how they interact to facilitate cross-ledger payments.

```Markdown
- **[1: Interledger Architecture](0001-interledger-architecture/0001-interledger-architecture.md)**

  Overview of the Interledger architecture.
```

--------------------------------

### Example JWT Bearer Token for RS256 Authentication

Source: https://github.com/interledger/rfcs/blob/main/proposals/0000-http-auth-profiles.md

An example of a JWT Bearer token used in the Authorization header for RS256 authentication. This token includes standard JWT claims like issuer, subject, audience, and expiry.

```HTTP
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2V4bWFwbGUuY29tIiwic3ViIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9hbGljZSIsImF1ZCI6Imh0dHBzOi8vZXhhbXBsZS5jb20vYm9iIiwiZXhwIjoxNTE2MjM5MDIyfQ.Vpa0XsMzFU95hPHhKYt8cd4HwbUz3F2Wt8tLXEkRZoU_z4xwktrfUxlrfOXZ5PxyVboDSZfNvUNhYawCx87M64JIyYDxGJbj1piu7m6F9_P3Qoi-h0bHmkk_K5x-CnFPqxBVhnWaqQFh3hzSzf0IHNJz5YMeZi4Mxgfxys-xcVKSrgel8xxMME4ns961ec49LurPpkvXIhXqsGXyBglgAe9tQBIpY-rbaq4dCLgHp6h2MFt-6h0z2HZ2B__uprRVoOOnK6s1-xQjS5wbKf7tez9u6o5ati2KjC94z8pOxG-OaCC4bW6G3aKjFwOtv4Xd-Qda1W37kda1cv4bb-qadg
```

--------------------------------

### Send ILP Prepare Request (HTTP)

Source: https://github.com/interledger/rfcs/blob/main/0035-ilp-over-http/0035-ilp-over-http.md

Defines the HTTP POST request structure for sending an ILP Prepare packet. It specifies headers like Host, Content-Type, Accept, Authorization, Prefer (for async), Request-Id, and Callback-Url, along with the OER-encoded binary packet in the body.

```http
POST /ilp HTTP/x.x
Host: bob.example
Accept: application/octet-stream
Content-Type: application/octet-stream
Authorization: Bearer zxcljvoizuu09wqqpowipoalksdflksjdgxclvkjl0s909asdf
Prefer: respond-async
Callback-Url: https://alice.example/incoming/ilp
Request-Id: 42ee09c8-a6de-4ae3-8a47-4732b0cbb07b

< Body: Binary OER-Encoded ILP Prepare Packet >
```

--------------------------------

### Interledger Glossary

Source: https://github.com/interledger/rfcs/blob/main/README.md

Contains definitions for key terminology used within the Interledger ecosystem, ensuring clarity and common understanding among participants.

```Markdown
- **[19: Glossary](./0019-glossary/0019-glossary.md)**

  Definitions of Interledger terminology.
```

--------------------------------

### Asynchronous ILP Prepare Accepted Response (HTTP)

Source: https://github.com/interledger/rfcs/blob/main/0035-ilp-over-http/0035-ilp-over-http.md

Shows the HTTP response when an ILP Prepare packet is accepted for asynchronous processing. A 202 Accepted status is returned immediately, indicating the packet will be handled later.

```http
HTTP/x.x 202 Accepted
```

--------------------------------

### XRP Payment Channels Tutorial

Source: https://github.com/interledger/rfcs/blob/main/0022-hashed-timelock-agreements/0022-hashed-timelock-agreements.md

A tutorial demonstrating the implementation of payment channels in XRP, facilitating off-ledger payment streams.

```HTML
https://ripple.com/build/payment-channels-tutorial/
```

--------------------------------

### HTTP Success Response

Source: https://github.com/interledger/rfcs/blob/main/0035-ilp-over-http/0035-ilp-over-http.md

Illustrates a successful HTTP response (200 OK) for an Interledger Protocol (ILP) operation.

```http
HTTP/x.x 200 OK
```

--------------------------------

### SPSP over HTTPS Connection

Source: https://github.com/interledger/rfcs/blob/main/0033-relationship-between-protocols/0033-relationship-between-protocols.md

Explains the Application-to-SPSP Server connection using SPSP (Simple Payment Setup Protocol) over HTTPS. This connection is used to retrieve end-to-end payment details, such as shared secrets and destination addresses, required for initiating payments.

```text
(C) SPSP over HTTPS
  - Application to SPSP Server connection
  - To determine end-to-end payment information such as a shared secret, a destination address and so forth, an application connects to SPSP server over HTTPS.
```

--------------------------------

### Decode ILP Timestamps from Fixed-Length String

Source: https://github.com/interledger/rfcs/blob/main/0030-notes-on-oer-encoding/0030-notes-on-oer-encoding.md

Illustrates the deserialization of the fixed-length ILP timestamp string format back into a standard ISO-8601 representation. It highlights valid formats and common invalid patterns that parsers must reject, including issues with UTC conversion and precision.

```text
20171224161432279 -> 2017-12-24T16:14:32.279Z
20171224161432270 -> 2017-12-24T16:14:32.270Z
20171224161432200 -> 2017-12-24T16:14:32.200Z
20171224161432000 -> 2017-12-24T16:14:32.000Z
20161231235959852 -> 2016-12-31T23:59:60.852Z
20171225000000000 -> 2017-12-25T00:00:00.000Z
99991224161432279 -> 9999-12-24T16:14:32.279Z
```

--------------------------------

### Example Payment Flow Across Diverse HTLAs

Source: https://github.com/interledger/rfcs/blob/main/0022-hashed-timelock-agreements/0022-hashed-timelock-agreements.md

Illustrates a typical Interledger payment flow involving different types of HTLAs across various ledgers and financial systems. It shows how Alice, using a blockchain with HTLCs, pays Bob, who uses a bank without HTLCs, through intermediary connectors. The Interledger protocol ensures security independence for each leg of the payment.

```text
Alice --(Blockchain A)--> Connector 1 --(Blockchain B)--> Connector 2 --(Bank C)--> Bob
```

--------------------------------

### Encode ILP Timestamps to Fixed-Length String

Source: https://github.com/interledger/rfcs/blob/main/0030-notes-on-oer-encoding/0030-notes-on-oer-encoding.md

Demonstrates the conversion of ISO-8601 formatted timestamps into a compact, fixed-length string format for ILP. This process involves removing separators, ensuring UTC representation, and handling specific cases like leap seconds and midnight.

```text
2017-12-24T16:14:32.279112Z ->  20171224161432279
2017-12-24T16:14:32.279Z ->     20171224161432279
2016-12-31T23.59.60.852Z ->     20161231235960852
2017-12-24T16:14:32.200Z ->     20171224161432200
2017-12-24T16:14:32.000Z ->     20171224161432000
2017-12-24T16:14:30.000Z ->     20171224161430000
2017-12-24T16:14:00.000Z ->     20171224161400000
2017-12-24T16:10:00.000Z ->     20171224161000000
2017-12-24T16:00:00.000Z ->     20171224160000000
2017-12-24T10:00:00.000Z ->     20171224100000000
2017-12-24T00:00:00.000Z ->     20171224000000000
2017-12-24T24:00:00.000Z ->     20171225000000000
2017-12-24T16:14:32,182Z ->     20171224161432182
2017-12-24T18:14:32.000+0200 -> 20171224161432000
```

--------------------------------

### Publishing a Proposal in Interledger RFCs

Source: https://github.com/interledger/rfcs/blob/main/CONTRIBUTING.md

This snippet shows the required front-matter and basic structure for submitting a new Proposal document to the Interledger RFC repository. It includes essential metadata like title, type, and draft number.

```markdown
---
title: The Interledger Architecture
type: proposal
draft: 1
---
# Interledger Architecture

Lorum Ipsum etc
```

--------------------------------

### ILP Packet Request Format

Source: https://github.com/interledger/rfcs/blob/main/0031-dynamic-configuration-protocol/0031-dynamic-configuration-protocol.md

Defines the structure of an ILP Prepare packet used for requests in the Interledger protocol. It includes fields for packet type, amount, expiration, execution condition, destination address, and data.

```ILP
Type: ILP Prepare (12)
Amount: 0
ExpiresAt: Arbitrary
ExecutionCondition: Zmh6rfhivXdsj8GLjp+OIAiXFIVu4jOzkCpZHQ1fKSU=
Destination: peer.config
Data: Empty (size: 0)
```

--------------------------------

### ILP Prepare Packet Structure

Source: https://github.com/interledger/rfcs/blob/main/0038-settlement-engines/0038-settlement-engines.md

Defines the structure of an ILP Prepare packet used for forwarding settlement-related messages. It includes fields like amount, expiresAt, executionCondition, destination, and data.

```plaintext
amount: 0
expiresAt: _Determined by connector_
executionCondition: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
destination: peer.settle
data: _Request message from sender settlement engine_
```

--------------------------------

### ILP Address Structure and Constraints

Source: https://github.com/interledger/rfcs/blob/main/0030-notes-on-oer-encoding/0030-notes-on-oer-encoding.md

Defines the structure and constraints for Interledger Protocol (ILP) addresses. Addresses must be between 0 and 1023 characters long and can include uppercase letters (A-Z), lowercase letters (a-z), numbers (0-9), hyphens (-), underscores (_), tildes (~), and periods (.).

```Text
ILP addresses have a length constraint of 0 to 1023 characters. Allowed characters include A-Z, a-z, 0-9, -, _, ~, and ..

Examples:
`example.top.middle.lower`
`example.very.long.address.to.exceed.127.characters.and.trigger.a.long.form.length.determinant.to.show.how.that.works.great.as.well` (newlines added for readability)
```

--------------------------------

### Async ILP Fulfill/Reject Reply Request (HTTP)

Source: https://github.com/interledger/rfcs/blob/main/0035-ilp-over-http/0035-ilp-over-http.md

Details the HTTP POST request used to send an asynchronous ILP Fulfill or Reject packet back to the origin connector. It includes the Request-Id for correlation and the OER-encoded packet in the body.

```http
POST /incoming/ilp HTTP/x.x
Host: alice.example
Content-Type: application/octet-stream
Authorization: Bearer zxcljvoizuu09wqqpowipoalksdflksjdgxclvkjl0s909asdf
Request-Id: 42ee09c8-a6de-4ae3-8a47-4732b0cbb07b

< Body: Binary OER-Encoded ILP Fulfill or Reject Packet >
```

--------------------------------

### Settlement Engines Specification

Source: https://github.com/interledger/rfcs/blob/main/README.md

Specifies an interface for sending and receiving payments across various settlement systems and ledgers, enabling interoperability between different financial infrastructures.

```Markdown
- **[38: Settlement Engines](0038-settlement-engines/0038-settlement-engines.md)**

  Specifies an interface to send and receive payments across different settlement systems and ledgers.
```

--------------------------------

### Synchronous ILP Fulfill/Reject Response (HTTP)

Source: https://github.com/interledger/rfcs/blob/main/0035-ilp-over-http/0035-ilp-over-http.md

Illustrates the HTTP response for a synchronous ILP transaction. It includes a 200 OK status and the OER-encoded ILP Fulfill or Reject packet in the response body.

```http
HTTP/x.x 200 OK
Content-Type: application/octet-stream

< Body: Binary OER-Encoded ILP Fulfill or Reject Packet >
```

--------------------------------

### ILP Packet Response Format

Source: https://github.com/interledger/rfcs/blob/main/0031-dynamic-configuration-protocol/0031-dynamic-configuration-protocol.md

Details the structure of an ILP Fulfill packet used for responses in the Interledger protocol. It includes the fulfillment, and data which contains the child's ILP address, asset scale, and settlement asset.

```ILP
Type: ILP Fulfill (13)
Fulfillment: 32-byte zero-filled octet string
Data: OER encoded SEQUENCE of:
  - Variable-length octet string: Child's ILP address (ASCII)
  - Uint8: Asset scale
  - Variable-length octet string: Settlement asset (UTF-8)
```

--------------------------------

### ILP Prepare Packet Structure

Source: https://github.com/interledger/rfcs/blob/main/0027-interledger-protocol-4/0027-interledger-protocol-4.md

The ILP Prepare packet, identified by type 12, contains fields essential for initiating a transfer. Key fields like 'amount' and 'expiresAt' are designed for in-place modification by connectors.

```Markdown
| Field | Type | Description |
|---|---|---|
| `amount` | UInt64 | Local amount, denominated in the minimum divisible unit of the asset of the bilateral relationship. This field is modified by each connector, who applies their exchange rate and adjusts the amount to the appropriate scale and precision of the outgoing account |
| `expiresAt` | Fixed-Length [Interledger Timestamp](../asn1/InterledgerTypes.asn) | Date and time when the packet expires. Each connector changes the value of this field to set the expiry to an earlier time, before forwarding the packet. |
| `executionCondition` | UInt256 | SHA-256 hash digest of the `fulfillment` that will execute the transfer of value represented by this packet. Connectors MUST NOT modify this field. The receiver must be able to fulfill this condition to receive the money. |
| `destination` | [ILP Address](../0015-ilp-addresses/0015-ilp-addresses.md) | ILP Address of the receiver |
| `data` | Variable-Length Octet String | End-to-end data. Connectors MUST NOT modify this data. Most higher-level protocols will encrypt and authenticate this data, so receivers will reject packets in which the data is modified |
```

--------------------------------

### Settlement Engines for Ledger Abstraction

Source: https://github.com/interledger/rfcs/blob/main/0001-interledger-architecture/0001-interledger-architecture.md

Implementations of Interledger are recommended to use settlement engines as defined in IL-RFC-38. These engines automatically settle obligations while abstracting the differences between various settlement systems and ledgers, ensuring interoperability.

```text
IL-RFC-38: Settlement Engines
```

--------------------------------

### STREAM Encryption Pseudocode

Source: https://github.com/interledger/rfcs/blob/main/0029-stream/0029-stream.md

Provides pseudocode for the encryption process used within the STREAM protocol. This section details the structure of the encryption envelope and the steps involved in encrypting data packets for secure transport over ILP.

```Pseudocode
function encrypt(plaintext, key, iv) {
  // Encrypt plaintext using AES-GCM with the provided key and IV.
  // Return ciphertext and authentication tag.
  return { ciphertext, tag };
}

function decrypt(ciphertext, key, iv, tag) {
  // Decrypt ciphertext using AES-GCM with the provided key, IV, and tag.
  // Return plaintext if authentication succeeds, otherwise error.
  return plaintext;
}
```

--------------------------------

### Sending Money with StreamMoney Frame

Source: https://github.com/interledger/rfcs/blob/main/0029-stream/0029-stream.md

Money is sent via ILP Prepare packets with a non-zero amount and a StreamMoney frame in the STREAM packet. The 'shares' field in StreamMoney frames dictates the distribution of the Prepare amount across multiple streams.

```Interledger
ILP Prepare packet with non-zero `amount` and `StreamMoney` frame in STREAM packet.
```

--------------------------------

### Interledger Protocol v4 (ILPv4) Specification

Source: https://github.com/interledger/rfcs/blob/main/0001-interledger-architecture/0001-interledger-architecture.md

ILPv4 is the core protocol for the Interledger suite, handling currency amounts, routing, and payment timing. It finds paths for payments through intermediaries and uses cryptographic conditions and fulfillments to ensure funds move correctly, proving delivery to the intended recipient. This protocol is defined in IL-RFC-27.

```text
IL-RFC-27: Interledger Protocol version 4
```

--------------------------------

### BTP Packet Structure Diagram

Source: https://github.com/interledger/rfcs/blob/main/0023-bilateral-transfer-protocol/0023-bilateral-transfer-protocol.md

A visual representation of the common BTP packet structure, illustrating the order and approximate size of its fields.

```text
  +---------------+ 
1 | Type (1)      | 
  +---------------+ 
1 | Request ID    | 
2 | (2)           | 
3 |               | 
4 |               | 
  +---------------+ 
1 | Length Prefix | 
2 | (3)           | 
  +---------------+ 
  | Packet-       | 
  | Specific      | 
  | Data          | 
  . (4)           | 
  .               | 
  .               | 
  |               | 
  +---------------+ 
1 | Sub-Protocol  | 
2 | Count (5)     | 
  +---------------+ 
  | Sub-Protocol  | 
  | Data          | 
  . (6)           | 
  .               | 
  .               | 
  |               | 
  +---------------+ 

```

--------------------------------

### StreamMoney Frame Structure

Source: https://github.com/interledger/rfcs/blob/main/0029-stream/0029-stream.md

Defines the StreamMoney frame used in Interledger for distributing ILP Prepare amounts across multiple streams based on shares.

```Interledger
StreamMoney {
  Stream ID: VarUInt
  Shares: VarUInt
}
```

--------------------------------

### Interledger Protocol V4 (ILPv4) Specification

Source: https://github.com/interledger/rfcs/blob/main/README.md

Specifies the Interledger Protocol (ILPv4) and Interledger Packet, which are fundamental for sending payment instructions across diverse ledgers and connectors. This is the core protocol within the Interledger stack.

```Markdown
- **[27: Interledger Protocol V4 (ILPv4)](0027-interledger-protocol-4/0027-interledger-protocol-4.md)**

  Specifies the Interledger Protocol and Interledger Packet, which are used for sending payment instructions across different ledgers and connectors. This is the core protocol in the Interledger stack.
```

--------------------------------

### ASN.1 and OER Encoding for Interledger

Source: https://github.com/interledger/rfcs/blob/main/README.md

Details specifications for data structures using ASN.1 notation and the Canonical Octet Encoding Rules (OER) for Interledger protocols. Changes are automatically checked and compiled using online ASN.1 tools.

```Markdown
## ASN.1 and OER

A number of the protocols define data structures in ASN.1 notation. The collection of definitions is in [asn1](./asn1).

Changes to these files are automatically checked and compiled during CI using online ASN.1 tools from OSS Nokalva. If you need ASN.1 tools for any work you're doing on Interledger please contact them for assistance.

[![OSS Nokalva](https://raw.githubusercontent.com/interledger/rfcs/master/assets/osslogo.png)](http://asn1-playground.oss.com/) 

You can also check your ASN.1 definitions online using OSS Nokalva's ASN.1 Playground available at http://asn1.io/ 

The default encoding rules for Interledger protocols are the Canonical Octet Encoding Rules as described in [Notes on OER encoding](./0030-notes-on-oer-encoding/0030-notes-on-oer-encoding.md).
```

--------------------------------

### ILP Packet Error Format

Source: https://github.com/interledger/rfcs/blob/main/0031-dynamic-configuration-protocol/0031-dynamic-configuration-protocol.md

Specifies the structure of an ILP Reject packet used for error reporting in the Interledger protocol. It includes an error code, a human-readable message, the triggering node's ILP address, and optional data.

```ILP
Type: ILP Reject (14)
Code: Appropriate error code
Message: Human-readable message
TriggeredBy: Parent node's ILP address
Data: Empty (size: 0) or additional debugging information
```

--------------------------------

### HTTP POST /accounts/:id/messages Request (Settlement Engine)

Source: https://github.com/interledger/rfcs/blob/main/0038-settlement-engines/0038-settlement-engines.md

Handles an incoming message from a peer's settlement engine. The connector processes the raw bytes of the message and returns a response.

```http
POST /accounts/:id/messages HTTP/1.1
Accept: application/octet-stream
Content-Type: application/octet-stream

> _<raw bytes of message>_
```

--------------------------------

### STREAM Protocol Specification

Source: https://github.com/interledger/rfcs/blob/main/README.md

The recommended Transport Layer protocol for most use cases, STREAM handles quoting, individual payments, chunked payments, and streaming payments by utilizing a shared secret between the sender and receiver.

```Markdown
- **[29: STREAM](0029-stream/0029-stream.md)**

  The recommended Transport Layer protocol for most use cases, which handles quoting, individual payments, chunked payments, and streaming payments using a shared secret between the sender and receiver.
```

--------------------------------

### HTTP POST /accounts/:id/messages Request (Accounting System)

Source: https://github.com/interledger/rfcs/blob/main/0038-settlement-engines/0038-settlement-engines.md

Sends a message to a peer's settlement engine and returns its response. The connector handles proxying the message through the peer's connector.

```http
POST /accounts/:id/messages HTTP/1.1
Accept: application/octet-stream
Content-Type: application/octet-stream

> _<raw bytes of message>_
```