OpenBazaar Roadmap

12 min readMay 9, 2016

Today we’re releasing our high-level roadmap for OpenBazaar, which you can find here.

In April 2016, OpenBazaar 1.0 was released to a better than expected response and has been used by thousands of people all over the world. We’re excited by our initial release, but OpenBazaar has a long journey ahead of it.

Our mission is to make trade free for everyone, everywhere. Our vision is for OpenBazaar to become commerce 2.0: a permissionless and censorship-resistant protocol for global trade using Bitcoin.

This ambitious destination will not be achieved in a 1–2 year sprint. Rather, OpenBazaar is a marathon, and we’re digging-in for the long haul.

While OpenBazaar will eventually power global trade in many different markets, our initial focus is traditional e-commerce for physical and digital goods, as well as services. The roadmap we’re releasing today reflects that focus.

Now, your favorite feature may be missing from this roadmap, and there are a couple of reasons why that is:

It is nested in one of the cards
It is too long-term for this roadmap
It doesn’t align with the mission/vision of OpenBazaar

We invite you to join our Slack group to discuss the roadmap in our #feedback channel.

Finally, OpenBazaar is an open source project. This roadmap represents things that the current regular contributors can achieve, and is subject to change with the participation of additional developers. If there is a feature you’re dying to see, but is low on our priority list, then submit code for the community to review and accept.

The Roadmap

First off, this is a ‘high-level’ roadmap, which means that the goal is to not get lost in the weeds with details about each feature we want to implement in OpenBazaar.

OpenBazaar itself isn’t just one thing. Fundamentally, OpenBazaar is a protocol with reference implementations for a server and client, which currently can be installed on multiple desktop operating systems. In the future, this development stack will expand to include other important platforms such as mobile.

With this in mind, the roadmap covers future features across the entire development stack.

The roadmap is structured using columns and cards. Each card is a general feature to be implemented, which are grouped together in the following columns:

Ongoing improvements
Short term (< 3 months)
Medium term (~3–12 months)
Long term (>12 months)

Before diving into the roadmap, we want to make it clear that it is obviously subject to change and shouldn’t be considered set in stone.

Ongoing Improvements

These features will continually be a work in progress. New sub-tasks will be added as the ecosystem matures.

Moderation System

The Moderation system in OpenBazaar is a minimum viable product, and relies heavily on third party platforms to discover and assess Moderators. Some future features in development are:

Moderator reputation system
Dedicated discovery of Moderators in the application
Dedicated Moderator page to display policies and precedents
Enable Vendor and Buyer to switch Moderators if the Moderator is unresponsive, or if they’re unhappy with the Moderator’s decision
Accept/reject Moderator terms of service
Reputation pledges: proof of burn, CLTV, surety bonds etc.

Another long term feature would be the creation of Moderator pools, with threshold signatures, which distribute and minimize the risk of collusion.

Listing Flexibility

This is a ongoing step towards bring the OpenBazaar listing UX on par with centralized platforms to enable:

Product variations (size, color, custom)
Shipping rules/costs
Tax rules
Coupons

Below is an internal article that looks how product variations are handled in other platforms from a UI/UX perspective, with implications for OpenBazaar (as well as calculating shipping costs):

OpenBazaar Listing Flexibility

There is a substantial amount of complexity when adding shipping and tax rules to a product.

medium.com

Reputation System

OpenBazaar reputation is built on transaction-based ratings. This is to say that an overall reputation score will be calculated from the aggregate transaction ratings they receive for each sale.

We are at the very early stages of building a robust reputation system for OpenBazaar. Thus far, transaction ratings are only visible within their parent listing. In the future, the overall reputation score and history of transaction ratings will be visible for each store on a dedicated page. Moreover, transaction rating data will be distributed across the network to prevent stores from hiding negative ratings.

Theoretically, third parties will also be able to access a Vendor’s rating data to calculate their own reputation score, or build a web-of-trust graph based on this data.

Privacy

One vocal criticism of OpenBazaar is the absence of network privacy, namely obfuscation of a node’s real IP address. This is typically enabled through the use of a VPN, I2P, or Tor, but most popularly with the latter.

There are a number of reasons why Tor isn’t supported in OpenBazaar 1.0, the most relevant being that it is simply not compatible with the rUDP transport layer currently used over Twisted for peer-to-peer network connections. This transport layer was chosen to enable UDP hole-punching so that we could have reliable connectivity between peers, which is one of our highest technical priorities. ZeroTier has written an excellent primer on this issue that I recommend, if you want to learn more.

Going forward, we will be upgrading the network backend to IPFS, which is discussed in greater detail below. This upgrade will be a significant step forward to eventually integrating Tor.

Discovery

Finding new listings in the application occurs by browsing the ‘Discover’ page or searching for relevant keywords. In the Discover page, browsing listings is split into two experience: Personalized and Random.

Personalized displays listings from nodes that you follow, whereas Random displays listings from nodes that you are randomly connected to, whether you follow them or not.

While browsing random listings is a novelty, and a bit of a wild west adventure, it is an unsatisfactory experience for users who may want to browsing listings by a specific category or type. To that end, we will be developing open tools to serve curated listings to users.

Documentation

The state of our documentation is incomplete, old, or unwritten. Writing first-class documentation of the OpenBazaar protocol and application is one of our ongoing objectives this year.

Short Term

The time-horizon for the deployment of these features is < 3 months:

Email notifications — email notifications triggered by selected events
Webhooks — will enable a raft of useful third-party services for OpenBazaar users (e.g. mobile notifications)
Backups — backup your store data locally or to a popular cloud storage provider (e.g. Dropbox, Box, Onedrive etc)
Order management — better visualization and management of orders at various stages of the purchase flow
Inventory management — batch listing importing, exporting, and editing; includes inventory tracking for listings
Order process UI — more intuitive representation of purchase flow stages and what comes next
Sales control center improvements — giving Vendors better visibility into comments, updates and general activity within their store front; includes store analytics
Advanced digital goods — automated delivery of digital goods upon payment; custom interface for certain types of digital goods (i.e. music)
Blockchain ID on-boarding — make the process of registering a blockchain ID occur within the application

Medium Term

Medium term improvements are some of the most exciting on our roadmap, and there are some big ticket items that will make 2016 a huge year for OpenBazaar.

Interplanetary File System (IPFS)

IPFS is a hypermedia protocol for building distributed file systems. We can view it as an extension of the OpenBazaar network architecture that allows for user data (such as listings and product images) to be distributed across many nodes in the network. Similar to BitTorrent, when you visit another user’s store, your node will download and begin seeding that store data to other users. This means that the more people who visit your store, the more your data will be replicated across the network.

The benefits to OpenBazaar users include:

Enhanced censorship resistance. With data spread across potentially hundreds or thousands of nodes, it will be impossible for would-be attackers to prevent others from reaching your content.
Persistent content. The goal is to make it so that vendors do not need to run an OpenBazaar node full time (although doing so will still be encouraged to help the network). Vendors should have the ability to close the app and still have their products visible on the network.
Multi-transport. IPFS has built in support for multiple transport protocols. The current transports include TCP and µTP (for UDP hole-punching) and can easily be extended to others.
Local connections. IPFS listens to a variety of network interfaces making it possible to connect nodes running on the same computer or same local network. The current OpenBazaar networking code lacks this functionality.
Improved DHT implementation. The IPFS DHT (distributed hash table) is already more robust and reliable than the current OpenBazaar DHT implementation. Looking forward, it makes sense for us to spend our time collaborating on a widely used implementation rather than trying to maintain our own.

Work has already begun if you’d like to contribute.

Improved search

The current search functionality consists of users “tagging” their products with keywords which are published in the DHT. While this is a purely distributed search algorithm, it leaves a lot to be desired. Search results tend to be inaccurate since it relies on Vendors tagging their products.

The switch to the IPFS DHT will improve the reliability of searching by tags, but we still feel the need to offer a more robust search experience.

Therefore we plan to introduce third party search functionality that will point the search bar at an API endpoint, which runs a crawler and indexes listings. While this is a “centralized” search function, users will have the ability to change the search API provider. The analogy here is similar to Popcorn Time where users view torrents which are fetched from API endpoints. If a particular endpoint goes down (as happens frequently in Popcorn Time), users can change the API provider to get the app back up and running.

For those who want to stick with the purely distributed search experience, searching by #tags will still be available.

Advanced Messaging

Real-time communication between nodes will be encrypted and authenticated using a TLS-like protocol (with ephemeral keys). That’s the easy part. The hard part is the development of a more robust system for sending messages to recipients who are offline.

Asynchronous messaging is needed in many places throughout the app. For example, sending chat messages, order and order confirmation messages, or dispute resolution messages to nodes that are not online. Ideally we would like to not only protect the content of such message but also the metadata. Furthermore, this must be done in a decentralized way that allows for reliable and scalable retrieval of messages… requirements that don’t usually compliment each other.

The working design places the responsibility for finding a suitable location to host the ciphertext on the sender (a variety of storage options will be available including IPFS). The sender publishes a pointer to the ciphertext in the DHT allowing the recipient to locate and download his outstanding messages when he comes back online.

The DHT pointers will use prefix filtering (hash of the prefix of the recipient ID), which will provide a tunable trade-off between privacy and bandwidth that will make it difficult for others to decipher who a given message is intended for.

To kick it up a notch, we plan to implement the Signal ratchet, the gold standard for secure asynchronous messaging, in the OpenBazaar protocol to provide forward and future secrecy. You can check out our progress here.

Tor Integration

We wholeheartedly believe that people have a fundamental right to privacy, especially financial privacy. Pursuant to this belief, we aim to integrate network-level privacy using Tor, in OpenBazaar, as a medium-term objective.

The open question is how best to integrate Tor. Most likely it will involve creating “onion only” nodes, which operate as hidden services that only take connections from other Tor nodes. The downside of this model is that it would likely segregate the Tor network from the main network.

Ideally, stores should be able to run in a “dual stack” configuration, where they accept connections from both clearnet and onion nodes. This will allow a store’s products to be visible on the main network as well as to Tor nodes. Some questions remain surrounding routing in a dual stack mode, as well as compatibility with IPFS, that require more thought and development.

Bitcoin Wallet

OpenBazaar uses a basic BIP32 wallet to manage multisignature escrow transactions in a user-friendly way. Ultimately, we want to include a full featured wallet in the application. The goal here is to make it easier for users to manage their bitcoin (especially those that are new to Bitcoin) and incur fewer bitcoin transaction fees when transferring funds out of the app.

One option is to integrate the lightning network daemon (lnd; node + wallet) for the following reasons:

lnd is written in Go, which is also the language used to implement the new OpenBazaar server powered by IPFS
lnd uses P2P simplified payment verification (SPV)
OpenBazaar transactions will be compatible with segregated witness
OpenBazaar will be compatible with the lightning network*

We will also be looking at creating well-documented APIs for third party wallet developers to interface with OpenBazaar.

*We’re in the process of mapping out how the lightning network will work in eCommerce transactions with multi-party escrow and will publish our findings at some point later in the year.

Mobile App

Mobile is eating eCommerce like software is eating the world. It is a forgone conclusion that OpenBazaar needs to be mobile. However, this is a complex objective with several technical challenges pertaining to OpenBazaar’s peer-to-peer architecture.

With the integration of Webhooks into the server, we expect to see an array of third party messaging bots (Slack, WeChat, Telegram, Facebook Messenger, Kik etc) that will relay notifications and messages from a remote node.

We aim to develop a client-only mobile application, which would empower users to fully manage their node remotely and securely.

Early stage sketch of a client-only mobile app

And More…

Some more medium-term features:

Offline Ordering. This is a significant addition to OpenBazaar. This will allow any contract to be posted anywhere, imported into OpenBazaar, and purchased. The purchase order is encrypted and hosted by IPFS peer, which is downloaded the next time the Vendor is online.
Groups and Private Listings. Enabling users to create public or invite-only groups to share listings that are only accessible by group members. This would be ideal for local trading in your geographic location, or for niche communities (e.g. sneakerheads). Similarly, we will enable Vendors to create listings that require a specific link or approved GUID to access.
Invitation to Tender/Job Postings. Create a listing that requests a good or service, with various parameters (e.g. price range, location etc), that Vendors can search and submit tenders for.
Improved Social Features. OpenBazaar can be thought of as an open platform to share user-generated content, as well as listings to sell goods and services. To that end, we will be adding more tools for users to share status updates and images to their followers to deepen their social and marketing interactions.

Long Term

These objectives are currently projected to take > 12 months to implement with our current resources:

Plugin system. This will enable third party developers to add functionality to the client and/or server without requiring any changes to core OpenBazaar code. For example, a great plugin would be something from Shapeshift.io to allow users to pay in/out of a Bitcoin escrow address with altcoins.
Shopping cart. A shopping cart would enable users to: (i) purchase multiple listings in a single transaction by funding multiple escrow addresses as individual outputs (saving Bitcoin transaction fees), and/or (ii) save shipping costs when purchasing multiple items from a single store (this feature may be bumped up the roadmap sooner time/resources permitting).
Contract flexibility. This is a sophisticated architectural change to OpenBazaar that would allow users to create their own custom contracts, with user-defined fields, interactions, and trade flow. Contract flexibility will allow for an expansion of OpenBazaar to facilitate any type of complex transaction.

Final Thoughts

OpenBazaar is and always was a mammoth project with an ambitious goal to become the backbone of global commerce. Every marathon begins with the first step, and we want to thank the community for their incredible support, enthusiasm, and patience.

We want to invite developers and volunteers to go on this incredible journey with us.