Skip to content

Latest commit

 

History

History
45 lines (26 loc) · 2.96 KB

README.md

File metadata and controls

45 lines (26 loc) · 2.96 KB
Raw

Quick Connect API

  • part of the torgap technology family

This section defines the spec for a deep link URI and a scannable QR Code. These ideally would have the same format among a number of different software projects and hardware products to ensure universal compatibility.

Quick Connect 1.0

Server-side node manufacturers or providers supporting this protocol include BTCPayServer, Nodl, MyNode, RaspiBlitz, and of course GordianServer. The iOS application GordianWallet offers proof of concept of a light client built to use this protocol.

Current Format

This example URL follows the current format:

btcstandup://<your rpcuser>:<your rpcpassword>@<your tor hostname>.onion:<your hidden service port>/?label=<optional node label>

The optional argument allows node hardware manufacturers the choice of hard coding a label for the node.

Example with label :

btcstandup://rpcuser:rpcpassword@kshcahsaihslalsichs78yb2ud8d.onion:8332/?label=Your%20Nodes%20Name

Example without label :

btcstandup://rpcuser:rpcpassword@kshcahsaihslalsichs78yb2ud8d.onion:8332/?

Ideally, there would be a two-factor authentication where a user inputs a V2 or V3 auth cookie into the client app manually, so that if the URL leaks somehow it would not give an attacker access to the node.

Quick Connect 2.0

We'd like to evolve this specification for 2.0 to address at least two new requirements:

  • There is a need to be able to offer multiple services from a single server, for instance Bitcoin mainnet, testnet, Lightning, Spotbit, etc. Thus primary goal for a Quick Connect 2.0 specification is a single QR from a server that can offfer a client a list of all services available to it.
  • A secondary requirement is that some servers may be able to use Web camera APIs to scan QRs from clients, and we'd like a QR with Tor v3 client information in it that can be passed back to the server.

We'd love to have more discussion with other wallet developers about any additional requirements for this initial connection between a full node and a remote device via tor. This could include a possible TOFU two-round auth so that the node can know that the specific remote device is the same one that requested it originally. If these QRs might get large, we might also want to offer this as an animated QR using self-describing UR format rather than javascript.

If you would like to participate in this discussion, we have it as a topic in the Airgapped Wallet Community