One aspect of the question regarding a possible relationship between blockchains and Open Badges is to wonder whether the blockchain should be treated as some kind of add-on to the existing Open Badge structure/standard, or should Open Badges be integrated within a blockchain?
A starting point for an informed answer to this question is to do a simple test: take an Open Badge generated by one issuing platform and try to import it into another issuing/hosting platform. I have done this experiment recently, taking only a very small sample, and the results were rather… (un)conclusive — BTW, one suggestion for the Standards Working group would be to run a real life interoperability test (not just through a formal proof) across all platforms and publish the results.
Interoperability is a classical problem to which the ePortfolio community was confronted some years ago and to which no convincing answer was ever provided — the IMS-Global ePortfolio and Leap2A specifications (2 specifications for interoperability is already one too many!!!) are only used by a handful of ePortfolio platforms — notwithstanding that there are many ePortfolios that do not use any ePortfolio platform at all! Moreover, when we organised plugfests during previous ePIC conferences, we had to admit that 3 platforms using the same technical specification (IMS ePortfolio at the time) had problems understanding each other: exporting one ePortfolio from one platform then importing it to another did not always work properly…
One could have imagined that with a structure much simpler than ePortfolios, the problem of interoperability would have disappeared. It has not. And now that we have allowed extensions to the specification, the order of magnitude for potential interoperability problems has increased geometrically, not just arithmetically. Yet, the possibility to extend the specification, even by one single issuing platform, willing to gain a competitive advantage, with a better or innovative service, should probably be allowed. We certainly do not want a “one-size-fits-all” issuing platform. Innovation must go on!
Are blockchains the solution to Open Badges interoperability?
While the current Open Badge architecture has already demonstrated its limit to interoperability, is there a way to ensure that every possible badge issued by one party will always be 100% compatible with the hosting service of the receiving party? Could the blockchain be the answer to that question?
A blockchain-based architecture guarantees that when someone writes on the public ledger, the writing is legitimate and legible. There might still be problems with the content of the writing if those writing on the ledger do not respect the expected structure for the content (therefore we will still need something like a data model for Open Badges) but, at least, sending and receiving badges will always work, the blockchain specification guarantees it. The decision to accept or refuse a badge belongs to the ledger, and as there is only one ledger, it will not be possible to have a situation where a badge accepted by one platform is rejected by another. The public ledger is a means to enforce interoperability in real time and not post facto.
So, if we decided to move Open Badge metadata from “pretty pictures” to blockchains we are sure that at least the infrastructure will be working properly — not withstanding the numerous advantages provided by blockchains themselves.
From Open Badges to BitofTrusts
The whole process of sending and receiving badges can be extremely unwieldy, starting with the obligation to create a “pretty picture” — and if one is not a graphic designer, use paint-by-numbers-canned-badges clip-art to generate “ugly pictures” — I made some time ago the suggestion of the “one pixel badge” and it was a total flop! There must be a better mechanism. It is what I would like to explore now.
Imagine that every individual and organisation joining the Badge Alliance (or some other overarching body) receives 1,000 BitofTrusts to be distributed to entities they trust (people, organisations, services and things (Internet of Objects). Let us say that the distribution of trust is treated as a deposit (unlike bitcoins) that can be withdrawn when you do not trust one entity anymore. Now imagine that trust deposits generate interests in favour of the holder of the trust (the host of the deposit) that can be used to further trust other entities. We would have the basic components for establishing the foundations of a trust economy — which is a somewhat redundant expression considering that there is no economy possible without anticipated trust. To complete the description of the infrastructure, one would assume that every entity has a place to store trust deposits. Let us call it a Passtrust (it would be a wallet in the Bitcoins world, theOpen Badge Passport or Badgr in the current Open Badge world and the Backpack in the old model).
To refine the model further, we could add algorithms mimicking the behaviour of local currencies such as the Chiemgauer in Bavaria, where the capital looses part of its value if not spent during the year after being acquired, the objective being to have a currency used to facilitate the circulation of goods and services within the community rather than a means to hoard.
At this stage, we have simply defined a general trust mechanism that is not that different from an idiosyncratic local currency. In order to align Bittrusts with Open Badges, we need to define a mechanism to represent values, affiliations, achievements or competencies. Instead of a pretty (or ugly) picture, we could simply use entries in a public ledger: When an entity gives a badge to another entity, this entity adds an entry in the ledger and deposits a Bittrust — it doesn’t have to be a complete Bittrust; 1/1,000th or less would do the trick for establishing a trust link between an issuer and a recipient. For endorsement, instead of creating a new entry, a fraction of a Bittrust would be added to an existing entry.
NB: one advantage of this mechanism over the current revocation of Open Badges is that the revocation information will remain within the ledger instead of being erased from the infrastructure. And knowing that a trust bond has been revoked could be a very useful piece of information — that should probably be erased after a few years to avoid lifetime stigmas…
Of course, I realise that what precedes is a rather crude description that needs to be refined further through thought experiments as well as mathematical and computational models — something we have not judged useful for the current Open Badge Infrastructure so far. The idea of giving everyone 1,000 BitofTrusts is just one option among many — it could be a certain amount each year, some entities might have the right to produce BitofTrusts and give them, not just as a deposit. I like the idea of having the trust others have in one entity generates interests in favour of this entity as it would be a tangible representation of the benefits of being trusted, but I am certain that there are other ways to achieving similar results.
All I wanted to achieve with this post is open a conversation, using blockchains as a “tool to think with,” opening new horizons for establishing a resilient, trustworthy, open and distributed Open Badge Infrastructure.
I am looking forward to your comments and criticisms.
NB: changed BitTrust to BitofTrust after publishing the next blogpost.
Originally published at www.learningfutures.eu on November 25, 2015.
Follow Us