adrianhopebailie

Generate a key using the node REPL

Needs JOSE npm lib. Easiest thing to do is just install it in a temp working dir.

cd /tmp
npm i jose
node

Inside the REPL:

adrianhopebailie

#include <ESP8266WiFi.h>
#include <WiFiClient.h>
#include <ESP8266WebServer.h>
#define SENSOR A0
#define DIGI_SENSOR D5
#define PUMPOUT D6

/* Set these to your desired credentials. */
const char *ssid = ""; //Enter your WIFI ssid
const char *password = ""; //Enter your WIFI password

adrianhopebailie

WebAuthN + Payment Request = Payment AuthZ

Can we use a combination of Payment Request API and WebAuthN API to get Transaction Confirmation (Dynamic Linking)?

Transaction Confirmation (TxConf) is a feature of FIDO that guarantees to the Relying Party (RP) that the user saw the same transaction details that are signed by their authenticator, i.e. WYSIWYS (What You See Is What You Sign)

Why is transaction confirmation important?

In the absence of TxConf an authenticator can ONLY assert that a challenge (generated by the RP to prevent replays) was signed inside the authenticator at the consent of the user (who provided the neccessary gesture to "unlock" the authenticator, e.g. biometric scan, PIN etc).

adrianhopebailie

import { Duplex } from 'stream'

export class Requestor {

  private _map = new Map<number, (reply: string) => void>()
  private _nextCorrelationId = 1
  private _stream: Duplex
  constructor (stream: Duplex) {
    this._stream = stream
    this._stream.on('data', (chunk: any) => {

adrianhopebailie

Interledger Service Provider Interface

The Interledger is a network of interconnected payment networks operating under a universal address space. To send a payment over the Interledger a sender has some practical prerequisites they must meet:

1. A source of funds
2. A connection to at least one other node on the network

For the majority of use cases, an Interledger payment will originate from, and terminate at, an entity that is on the limits of the network graph. That entity may have more than a single connection to other nodes but will not be operating as an intermediary node. For clarity the node(s) that this entity connects to is/are defined as an Interledger Service provider (ILSP).

The ILSP provides services to senders and receivers that allow them to send and receive payments via ILP without needing to be fully functioning ILP nodes. These services include one or more of:

adrianhopebailie

ILP-Kit - Web Payment App

The W3C Web Payments working group have published a specification for web-based payment apps, web applications that can handle Payment Requests from other web applications.

The Editor's Draft (latest version) of the specification for the Payment Handler API is at https://w3c.github.io/payment-handler/

Thus far only Google have implemented this specification in the latest version of Chrome Canary for Android. Other browsers are expected to follow.

There is a rudimentary example of a web-based payment app here: https://github.com/madmath/payment-request-show/tree/master/bobpay/public/pay

adrianhopebailie

Assuming https://example.com/ is ILP Kit URL

POST {"username": "", "password": "" } to https://example.com/api/auth/login

inspect response.headers.set-cookie and use as cookie for future requests

POST {“destination”:“<SPSP Endpoint URL>”,“sourceAmount”:null,“destinationAmount”:“<Amount>”} to https://example.com/api/payments/quote

adrianhopebailie

Keybase proof

I hereby claim:

• I am adrianhopebailie on github.
• I am adrianhopebailie (https://keybase.io/adrianhopebailie) on keybase.
• I have a public key ASDWPiZ_g_dE5QohrkjutcKS134trzdROmjDbCvNMi2mIQo

To claim this, I am signing this object:

adrianhopebailie

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

This includes both the logical data model and the serialization.

ILP requires the following messaging channels and messages:

Client <-> Ledger
    
 -&gt; Request Ledger info

adrianhopebailie

Response to thread on zCash forums:

Hi Zooko,

Adrian here from the Interledger Project. The use case you describe is exactly the one we're trying to address with Interledger. Thanks Brett Carter for pointing me to this thread.

Ito interoperability, Interledger takes the approach of providing a protocol for inter-networking payment networks (in a similar manner to how IP solves for inter-networking between data networks). So rather than trying to provide any features that should be ledger/network specific Interledger simply addresses "How can value be transferred from an account on one ledger to an account on another, reliably?" It is completely ledger agnostic and actually very very simple.

The protocol depends on Conditional Payments on each network, however it is possible to work around this if the two pa