Concords: It’s like git but in the browser.
A little while back we published a post — What Is Concords? — which was an early thought gathering process around a way to communicate our fairly niche technical concepts, to a more generic technical audience.
The purpose of that was to explain an idea to some close friends and get feedback on an initial prototype, a minimum-viable-product for a boards app.
The post ended up getting more traction than we’d anticipated and raised a few questions along the way. So I’m back again to try and dig a little deeper into some of the concepts we’re exploring here at Team Concords.
Blockchain: The elephant in the room
I made a mistake in my previous post, I used the word blockchain.
Blockchain has dominated tech news around decentralization for the past few years. Smart-Contracts this, Crypto-Currency that — Bitcoin here, Etherum there… you get the point.
I used the term blockchain as it’s recognised. You can assume a certain understanding of how a blockchain works from a technical audience. But what I ended up doing was putting us into a category we don’t really belong. We’re not a blockchain project, what’s really powering data integrity in Concords is our Merkle Tree — Wikipedia implementation.
Concords is like git, but in the browser.
So the principles behind Concords are a lot like git, but running in the browser.
For those not familiar with Git, I probably can’t explain the benefits to you. For those who do use git, I shouldn’t need to.
When you perform an action in Concords we add a new transaction to the document using a CRUD interface, so the app itself is built much the same as an app using any standard CRUD API interface.
Our difference is that rather than send data over to a server and update a remote database, we add these actions to a transaction pool within the document which can be stored and saved locally to the user. You’ll see as you add a new action that the “commit” button appears.
The commit functionality is much like git, we take the group of transactions and commit them as a new transaction block to our document. This is secured through our Merkle Tree with cryptographic hashes, which gives us our data integrity. Once commit, the document can then be saved and shared, when a document is opened through the app the transactions are parsed and applied to the runtime DB.
The concept of Push and Pull right now is dealt with by a simple Save and Load feature. As our architecture matures we’ll start exploring integration with networking, I’m taking a guess that our save and load features will map out like push and pull in Git — hopefully with us providing hooks to plug into any storage solution.
What’s in a document?
The Concords Document is a JSON structure of state. When a document is loaded into the app, it plugs into the runtime and is used a the source of truth for data.
With a standardised document format, any custom frontend can be built following web standards. Replacing network requests with document writes. Once the document has loaded the app it’s plugged into a reactivity hook — this keeps the document performant and up to date.
Whilst we’re still in the MVP stages, we’re building app a bunch of different frontend solutions to ensure we have fully functional apps.
Some examples we’ve built on the platform internally:
- Document portfolio with Markdown Editor
- Simple Sheets style custom tables
- Messaging system (with some WebRTC real-time p2p tests)
- Todo List
Is it really offline if it’s in the browser?
Absolutely it is.
The browser’s a fantastic platform, which doesn’t require a connection for its runtime, it’s a portal to run static apps on remote servers.
All you need a connection for in Concords is for the initial download of the app. We use a Service Worker to cache static content, so once you’ve got them for the first time you can run things completely offline.
Why the Browser you ask? Here’s a little list of some key reasons the browser is the perfect place for this project.
- WebCrypto API
- IndexedDB
- WebRTC / Sockets
- Device compatibility (web / desktop / mobile / IoT / headless)
- Connectivity
How are our files shared?
Trick question. They’re not, that part is down to you.
We’re not developing a web architecture for p2p decentralization. We’re building practical web apps with artefacts. It’s like combining the versioning patterns of git, with the portability of PDFs.
We want to be able to provide a frontend to any backend and allow users to chose where they store their content. The MVP works currently if you want to share documents manually through Slack, Dropbox, OneDrive, USB stick, DAT foundation, CDROM(??) etc…
If you’re a developer you really do have the freedom to chose how you manage document storage. We handle validity and authentication of a document at runtime, although we’re still in the early stages of fully building out the validation flow.
