Which components are actually required?

Wallet & Headers Only

If you're running things from a network which is exposed to the internet with firewall rules under your control, only the Wallet and Block Headers Client are required.
What it does
  • Stores users, invoices, transactions, keys, and proofs
  • Validates transactions against block headers
  • Broadcasts transactions to miners
  • Connects to other wallets directly for payments
  • Exposes an API to interface with
  • Stores block headers
  • Connects to the node network p2p
  • Exposes an API for the Wallet

With DPP Proxy

For routing payment requests to a wallet which is not exposed to the internet.
What it does
DPP Proxy
  • Stores relationship between paymentIDs and socket connections
  • Exposes DPP API endpoints
  • Routes payment messages between corresponding parties

Example Use Case

Bob is running the Wallet locally on a laptop, and he is at an airport. Alice, who wants to send Bob a payment directly, cannot reach his Wallet through the airport wifi. In this case, Bob's Wallet can be configured to connect to a DPP Proxy service which is exposed to the internet. Alice's request will then relay through the proxy to Bob over a secure web socket connection.
DPP Proxy used when direct communication is not possible

With Peer Channels

For allowing Wallets to go offline while they waiting for their transactions to be included in a block. A secure inbox for Merkle proofs which miners write to, and payment counterparties read from.
What it does
  • Manages access to secure persistent message channels with read & write tokens.
  • Exposes endpoint to write Merkle proof when registered transaction is mined.
  • Allows Wallets to subscribe to notifications via secure web socket
  • Allows Wallets to read Merkle proofs from channel as needed
  • Stores Merkle proofs while counterparty wallets are offline

Example Use Case

Bob broadcasts a transaction he received from Alice using a Mapi service hosted by a well known block producing miner. He shares a write token, and sets the callbackURL to:{txid}
Bob subscribes to Peer Channel notifications, and sends a URL and read token to Alice so she can do the same.
Eventually a block is mined, at which point the miner writes the Merkle proof to the Peer Channel via the callbackURL. It captures the proof and notifies Alice and Bob. Each reads the channel whenever they can.

With Paymail Server

Solely for the purpose of migrating funds from external wallets. The Paymail standard is common to most web wallets, so this server will act as a bridge from those wallets to the world of SPV.
What it does
  • Stores relationship between an alias and a Wallet user
  • Exposes a web API for the minimum required paymail capabilities to be compatible with industry wallets
  • Translates between Paymail & DPP protocols

Example Use Case

Alice is setting up her SPV Wallet for the first time. She doesn't have a way to pay an invoice because there are no DPP wallets in the market yet. She sets up the Paymail Server which allows her to send a payment to [email protected] from her regular web wallet. Now she has funds in her SPV Wallet which she can pay invoices with using DPP.