This is very much a WIP page, meant as a sketch to share some of our thinking and research publicly
We are exploring the usage of IPFS and some of the other pieces of the Fission protocol stack in order to tackle interesting problems.
The most well-known usage of Payment Channels is probably the Bitcoin Lightning Network (Wikipedia).
Our stack means these functions can work in any browser, without plugins, including on mobile, and without necessarily needing a crypto wallet, although our approach to private keys in the browser means we can create secure wallets on the fly as well.
And, as mentioned below, you could also settle payments via PayPal, Stripe, or other regular currency providers, if participants trust the provider (e.g. Fission or Open Collective could hold funds, and disburse funds on a monthly basis).
Browser based payments can be interesting for a number of use cases, like app purchases and licensing, content micro-payments, and so on. The Web Monetization standard is one we’re following as well.
This is an initial high level write up. We’re exploring interest in this and what system(s) would like an implementation. Please get in touch with @boris or @expede in our Discord chat, or leave a comment, if this is interesting.
Payment channels on IPFS is essentially a port of state/payment channels. It has the following broad technical requirements:
- A way to transmit messages
- Well known public keys
- A way to sign transactions (e.g. RSA signatures)
- A way to store transactions
- A settlement layer that is capable of enforcing a dispute period
- Recommended: a way to find valid paths through a graph
- Optional but ideal: a notification method
Upsides
Payment channels are extremely lightweight, instantaneous, and distributed. As soon as a transaction is countersigned, it’s done. You only need to rely on a third party at the very beginning (lockup) and the very end (settlement).
Prior to settlement, you can make as many updates as you like for free, and as fast as you can countersign them. This allows for streaming and/or micropayments.
You can use other people’s channels to settle your state, as long as there’s a fully connected path with enough state between you and the recipient. This leverages the network and makes it much more valuable than between individuals. In some systems, the delegate channels can additionally collect a fee for their service.
Channels tend towards federation. Anyone can permissionlessly operate a “bank” or “hub” (and peer with a large number of connections). It’s actually advantageous for them to exist: by having very short paths between two users (because they’re connected by fewer of these hubs), the system becomes more efficient when doing transitive payments.
Downsides
In most formulations, you’re required to lock-in the amount of money in your channel up front, to the settlement layer. This means that if you need that cash, you must either close out that entire channel. If you want to add more state to the channel, you need to either open a second one, or settle and repoen with the desired funds.
General System
They all work on the same principle, and slotting IPFS paints in a large part of the final design. The big part that changes is what the settlement layer looks like. Store the receipt chain on IPFS with a DNSSEC-protected DNSLink. Since everything is countersigned, both parties have a copy, and thus it’s very hard to cheat.
Pure IOU (AKA Invoicing?)
Aside: “Pure IOU Service” shortens to… PIOUS?
This version looks a lot like SplitWise.
- Users broadcast their signing key (e.g. DID) via e.g. DNS
- No lock-in, this is a handshake deal
- A channel is a hash-chain of countersigned receipts
- When settled offline (e.g. cash), they countersign a closeout receipt
Trusted Fiat Provider Network
Settlement layer is done in fiat. This can be cross-currency, though exchange rates get complicated.
- Alice and Bob send funds to the provider (“bank”)
- They open the channel, also signed by the provider
- Exchange back and forth
- Bob submits a receipt to the provider
- Alice has a week to provide a newer receipt, and override Bob’s (starting the dispute period again)
- Alternately Alice can agree to release the funds in under that time
Blockchain
Use a smart contract (e.g. Ethereum/Filecoin/Cosmos) instead of the trusted authority. Encode the lockup & release logic directly in the contract. Store the actual receipts on IPFS.
Full blockchain alternative
Nano uses a blockDAG to achieve a similar goal, also will countersignatures. There’s more community involvement to check on the state.