By: Henk van Cann
How can a blockchain be meaningful for a CMS like Drupal? — keep reading.
Famous speech of John F. Kennedy, president USA in 1960’s ‘what you can do’
The title is the abstract. The article is aimed at current reputable CMS web-based frameworks like Drupal, Wordpress, Joomla, Hippo, Rails, Django, etc.
Why this blog post?
Dries Buytaert creator of Drupal raised a simple, yet extensive question on twitter (‘@Dries’):
“What could the Blockchain mean for a CMS like Drupal? #brainstorm”
Let us analyse this question step by step. And then come to a surprising conclusion: it is much more interesting for Drupal to change the question.
“The Blockchain“ is written with a capital ‘B’ and if that is done on purpose, it refers to the Blockchain protocol and the word ‘the’ implies that we look at the blockchain under the hood of the bitcoin, running the Bitcoin protocol. Focus makes life easier.
Besides technical features, public blockchains are expected to have a political and ideological impact. I choose the more technical approach in this blog post, for the sake of clarity, practical application and more focus. (Which again makes life easier.)
A CMS manages content on the web, using a permissioned and centralised database. However, a public blockchain is a verification machine without the need of a middleman and offers pseudo-anonymous permissionless access to a single global ledger. Big difference…
Aren’t there any commonalities? Sure! Drupal shares the following features with The Blockchain:
- internet based
- open source
- for free or at very low costs
- a developers community
The bitcoin blockchain differs from a CMS like Drupal:
- it is not a web-application
- it is an explicit transactional system, unlike the content store that a CMS is, as it uses implicit transactions
- it does not contain a relational database
- it is slow
- it has a low transaction rate (7 tx/s)
- it consumes an enormous amount of energy
- transactions are irreversible, meanwhile CMS database changes are reversible
A blockchain would be a “fremdkörper” in a CMS
So back to the question “What could the Blockchain (of the bitcoin) mean for a CMS like Drupal?” Not much at the moment. Because the true nature of a web based CMS like Drupal, Wordpress or Joomla is so different from a blockchain, that adding blockchain features to the CMS environment, would be like introducing a fremdkörper: a component or additive that renders something else that is impure.
It makes no sense to add inefficient decentralized features (for the sake of freedom) to a centralized, highly efficient content management system.
Examples of Drupal modules that learn(ed) this through experience:
- https://www.drupal.org/project/commerce_blockchain discontinued (well done! their motivation is convincing)
- https://www.drupal.org/project/uc_blockchain no local full node, so no real blockchain implementation, just an API (well done! stick to your core business)
- https://www.drupal.org/project/uc_bitcoin Continued, look at their struggle though: Their open issues (June 2016) all have to do with non-Drupal stuff attached to the Blockchain. Why do it yourself? Use BitPay or any other well-equipped bitcoin payment portal. Beware of the fremdkörper.
Well, if it there is no clearly identifiable match, what to do instead?! The Drupal community somehow must anticipate the blockchain-tsunami that we anticipate.
This is what any open source CMS community could think about the following issues: Which problems do we want to solve (with a blockchain) that could not be solved before? And why would we need an inefficient intermediate-less worldwide verification machine to do that? What freedom do we strive for that we could not reach before?
- in the core of our framework
- in the components of our framework
- in the implementations of framework + components
Let’s take a pretty straightforward example: webshop components (2.). Every CMS has them. We all recognise the high costs of international money transfers. Whether you use a payment provider or not, transferring and receiving small amounts of money will have a substantial percentage of “wasted money” paid to middlemen (pp’s and banks). <- suppose we consider this as a problem we need to solve.
If we would accept bitcoin in the web shop (and not use the bitcoin-service of any middleman), we would need to provide functionality:
b. exchange to and fro fiat currency,
c. transaction (confirmation /validation) functionality and workflow.
Yes, we would need an intermediate-less verification interface to the Blockchain. However: No! This would not significantly add anything to the freedom we already have available. Nowadays, there are many payment service providers that offer bitcoin payment services. Their mutual competition will settle a decent price for you that matches current economics. As a component builder for Drupal, you just have to pick one or switch to one that does a good job.
Blockchains introduce other problems and inefficiencies.
Conclusion of this example: We don’t need to address a blockchain ourselves to improve payment providing. And by doing so (use a blockchain directly), we would introduce other problems and inefficiencies.
Most of the times we do not need a blockchain
Go over every use case a dozen times. Most of the times, we do not need a blockchain. I learned that the hard way from bitcoin Core developer Peter Todd. If you’d like to know more, read the blog post ‘Approach Blockchain Enthusiasm as a Devil’s Advocate’.
Identity, never a dull moment
Any other problem that we have that we could solve with the blockchain? …
Pretty quickly, people will come up with ‘Identities’! Dave Birch, the writer of ‘Identity is the New Money’ (2014), recently said: “Every discussion about the blockchain boils down to Identity issues within 1o minutes.” And it really does! Visit any blockchain meetup, conference, brainstorm session, Proof of Concept or whatever, there is never a dull moment around Identity & Access Management.
How come? And could we tackle this with blockchain? Are we better off now the Bitcoin proofed to be stable?
The authentication and authorisation of e-identities is a trade off everywhere on the web between between privacy, efficiency, security and ease of use. More specifically, e-Identity is an area of interest that has a theoretically and fundamentally love-hate relationship with public blockchains. That’s one angle to consider. However, the other perspective is that there seems to be hardly any killer app discovered for e-Identity that benefits from a blockchain. Or at least no killer app where CMS frameworks like Drupal could benefit from directly.
Let us turn the question around: What can Drupal mean for the Blockchain and any other blockchain? A lot! Blockchains are in their early stages of development. And here is the shocking answer: A whole lot, right away!!
My bet: Build Drupal connectors (modules) for anything that public blockchain developments need. That applies to the Bitcoin Core of course, but also to exchanges, portfolio management tools, wallets, BaaS (yes, yes), etc.
They all suffer from these needs:
1. to bring the blockchain functionality to a bigger audience (e.g. two-way pegged side chains, the lightning network, hyperledger)
2. to improve the UX (blockchain apps have GUI’s that brings us back to the last century)
3. to improve the workflow (blockchain implementation are in their infancy)
4. to improve the safety (unintentional mistakes can be very costly because they are irreversible), etc.
One for the Drush road
Most development environments for blockchains are command-line based. One could consider extending Drush with Core blockchain-specific commands or features.
Conclusion and my ‘2 cents’
Don’t ask what the blockchain can do for you, ask what you can do for the blockchain! That will effectively bring any reputable framework into the blockchain game. And your community could start learning while continuing to rely on the own strength the framework has had for years. Step by step, with not too much at stake.
My ‘2 cents’: Build bridges, connectors, components, API’s, user-friendly front-ends to blockchains and watch all of these tools either flourish or die. Leave public blockchain Cores for what they are: rather inefficient global verification machines based on cryptography and time-stamping.
Imaginary acknowledgements / thanks : middle