Logo

An Update Regarding Origin Messaging

March 20, 2019
story-fb-cover-image.png

In August last year, we announced the addition of a new decentralized messaging system to the Origin platform. We knew it was important for buyers and sellers to have a way to communicate with each other, whether to answer questions about a product or to communicate sensitive details after an offer is accepted. When designing our messaging system, we wanted to provide the fast & free experience that users have come to expect from modern messaging platforms, without compromising on security.

Since our initial launch, we’ve had the chance to reevaluate some of our initial design decisions. We received a lot of feedback from our users that our messaging system was not as fast and reliable as we had hoped. One big challenge in our design was our reliance on OrbitDB, which is a distributed, peer-to-peer database that runs on IPFS. We still love the idea of enabling trustless messaging without any centralized servers involved, but our OrbitDB implementation didn’t scale. As our DApp has gotten more usage, our messaging system has become increasingly less reliable. Our plan was to eventually implement sharding, but we came to the conclusion that OrbitDB is probably just not a good fit for our particular use-case.

Meanwhile, our views have shifted in what features matter most for messaging on a decentralized platform. We originally started with the assumption that messages should be saved forever and we were storing them on IPFS, which aims to be the “permanent web”. Today, we’re less convinced that level of persistence is desirable. We’ve had a hard time coming up with reasons why you need your messages to be recorded for all eternity. In many cases, there’s a good argument for why your messages should be ephemeral or at least easily deletable. We’re not alone in our thinking. Mark Zuckerberg recently cited “reducing permanence” as one of the design goals for Facebook’s future privacy-focused messaging system.

In conversations with our users, we consistently heard that they valued performance and reliability over decentralization. What matters most is not how the messages are transported from one computer to another. The important thing is that the messages are encrypted end to end, meaning they are encrypted in the sender's browser and stay as unintelligible 1’s and 0’s until they reach the recipient's browser where the original message is decrypted. This means you only need to trust a relayer to forward along the message, but your privacy will not be compromised even if the relayer turns out to be malicious or is even given a court order to reveal your conversation.

In the interest of having reliable, performant messaging, we’re switching to a relayer model where messages sent in the Origin DApp will be forwarded to the recipient via centralized servers. These relayer servers are currently operated by Origin as a community service. While this means we now have the power to delete messages, we’re using the exact same encryption scheme as before, so we can’t read them unless the buyer or the seller invites us to join the conversation. Since we’re using the same encryption scheme, we were able to import all the previous messages that were stored on OrbitDB into a good old fashioned database, which we’ll be using going forward. The end result is that our DApp loads a lot faster and our messaging system is a lot more reliable.

This is unlikely to be the final update for Origin Messaging. We’re continuing to research ways to make our messaging system more decentralized and trustless, while still offering the features and functionality that users care about. We also know there are other teams working on similar challenges and we’ll be following their progress as well. We’ll keep you updated with any developments or future changes to our platform.

Learn more about Origin:

Josh Fraser
Josh Fraser
Origin
Stay in touch
Be the first to hear about important product updates. Your email will be kept private.
Originally released by Origin Protocol
Privacy policyTerms of service