If you haven’t already, stop what you’re doing and read the Subspace readme right now and checkout their website. In short, Subspace is network of federated servers that enable users to share encrypted messages.
Key features of the Subspace protocol are (as per the readme):
- All messages are encrypted with only the sender and recipient able to decrypt.
- The sender’s identity is not attached to the message at all and the only a user-defined number of bits from the recipient address is attached to the message. In other words, no meaningful data is available to passive observers.
- By splitting the message load among servers (possibly with a financial incentive), the network can scale to handle a very large number of messages.
- Because the network is server based, servers can implement traditional anti-spam measures without harming user experience.
- The protocol supports lightweight queries allowing the user to make the anonymity set/bandwidth tradeoff.
- The protocol supports market based rationing mechanisms where necessary.
This protocol was developed by the ever talented Chris Pacia, from Bitcoin Authenticator, who significantly impressed several of us when he circulated his initial proposal… but then shocked us with how quickly he implemented his proposal in just a few weeks. I think there’s a lot to be said about this model of development: lean, fast, and with a singular focus on making something.
Currently, Subspace supports 3 types of communication:
- Instant messaging between two peers
- Email (only to other Subspace addresses)
- Public or private chat rooms
This is just the beginning of what can be developed on top of Subspace, but already a significant number of things can be accomplished with OpenBazaar using these initial features.
There are several potential applications for Subspace within OpenBazaar. I will go through a few of them and unpack how they might work
1. Ricardian Contract Hosting - Subspace can be used by merchants to upload OpenBazaar Ricardian contracts for persistent and private accessibility.
Currently, as with most distributed hash table (DHT)-style p2p networks, content can only be retrieved from a node if it is online. The implications of this is that a merchant would need to run their OpenBazaar node 24/7 in order for potential buyers to access, view, and purchase contracts they are selling. This may not be an option for most merchants, and it is an area where Subspace is ideally suited to solve.
A user will create a contract, submit it to Subspace federated server, who will store the contract either gratuitously or for a small fee over a negotiated period of time. The Subspace server will store the contract and associate the contract with the merchant’s OpenBazaar GUID within the Subspace DHT. When a potential buyer wishes to download contracts created by a certain merchant, they can submit a request from any Subspace server using the merchants GUID as a search term. The server will either return the contract directly (if it stored on its HDD) or search the DHT for the Subspace server that does, and retrieve the contract for the user. Moreover, the contract can be encrypted using key that only the contract participants can decrypt (similar to Bitcoin stealth addresses). This will enable contracts to be stored in Subspace, and referenced in the DHT, without any OpenBazaar GUID associated with the contract.
2. Multiparty communication - private communication and contract creation between market participants
A typical exchange within OpenBazaar involves 3 parties: a merchant, buyer, and notary. Within the Ricardian contract schema, the participants can indicate their email address or other communicative ID for contract related discussion. The contract schema can be modified to include a Subspace address and private room key (where other users can query the merchant about the contract if they’re online). Conveniently, the private room key can be identical to the contract nonce. Once the contract has been signed by all parties (i.e. merchant, buyer, and notary), these parties can chat privately using Subspace’s email or private chat room service.
Under the current design, the contract creation process begins with the merchant and then ping-pongs between participating nodes. At each stage, the buyer or notary appends relevant information (e.g. ID, tracking number or digital signatures) and passes the contract to the next party until the contract is completely filled in. Alternatively, a Subspace server could act as a central repository of the Ricardian contract, with push access granted to the market participants.
Using Subspace's chat room feature, specialised chat rooms or ‘market channels’ can be created for categories and subcategories of goods and services where merchants can advertise. While the Subspace server network is Federated, each server will have individual leasing policies for storing data. A possible outcome is for Subspace server operators to charge a subscription fee to prospective OpenBazaar merchants to advertise their goods on a market channel they host. Furthermore, OB-specific market channels may be modified to accept ‘seed’ Ricardian contracts only (i.e. the initial JSON-formatted contract for the item) rather than plain text posts.
Auctions in OpenBazaar are expected to be developed later in 2015. While contracts and auctions can be decentrally distributed and managed using the merchant’s node (or a proxy node with high bandwidth capabilities), they can also be managed via Subspace. The advantage of using Subspace over OpenBazaar’s DHT are relative to the user, but it would allow for casual users to upload their contract and automatically execute the bidding process without operating a node during the period of the auction. In other words, merchants can ‘fire and forget’ contracts they put up for auction, returning to the end of the auction period to finalise the OB Ricardian contract with the winning bidder.
Bids may be uploaded, stored, and pulled from multiple Subspace servers; however, updating the contract with the latest price based on the bids will be done by a single Subspace server (who theoretically will have better bandwidth and uptime capacity compared to a user’s node). Bids can be submitted via a public chat room modified to only accept JSON-formatted OB contracts (not plain text) to minimize the potential for spam.
Subspace has the potential to become a powerful tool to enable market discovery and coordination, while preserving the privacy of individuals purchasing goods and services. Further work is necessary to develop the APIs to enable most of the features listed above, as well as both Subspace and OpenBazaar clients.