Tuesday, May 12, 2009

MetaCurrency and Cyclos - Clarifications on Open

It has been requested that we try to describe the nuances of “open” and how the MetaCurrency Project compares with Cyclos in this department. I am not sure I am the best person to do this (Arthur and Eric are definitely more qualified), but here is my best attempt to describe the various types of openness we are talking about.

Open source is great. This means being able to openly access source code, change it, and share changes with a community of developers. Very awesome. And for Cyclos’ open sourceness I heartily applaud it.


However, when people set up an instance of Cyclos, they are establishing a place where users have to set up an online identity (or account), and that ID is only relevant to that currency. I can’t use my ID to participate in other currencies or access other currency platforms (like GETS), so it is a closed network. I also can’t use my ID to set up a new currency with access to the same user base. This means that if the governance (no matter how inclusive) screws up, the users become scattered. People wanting to trade become dependent on a structure that may not serve them, because the currency is operating in a informational silo.


In contrast, if I could use my ID (or account) to establish new currencies or participate in any existing ones, the ecosystem of currencies could freely evolve. It wouldn’t be a huge deal if one currency turned out to be flawed because anyone using that currency would be connected to the broader network and could simply play a new game.


Before SMTP, email was similarly challenged. I could email others using the same service provider, but I couldn’t email people outside the service. So, open standards are the key. When SMTP was invented, email took off. When HTTP and HTML were invented, users could suddenly get ANY information resource from ANY server, and the world-wide-web was born. Closed networks (like Prodigy) didn’t provide that kind of dynamism, so they quickly disappeared.


The MetaCurrency Project is doing the same thing for currency as HTTP and HTML did for the web. It is establishing a simple protocol for defining a currency game, and making a play in that game. So anyone using a currency service provider will be able to play in any game they choose or start new games of their own design. That is very different from anything that has come before in the currency world.


What really excites me about this new world is the implicit invitation to developers to make client software that serves different needs. Firefox, Safari, Chrome, and Flock are all browsers that serve different needs, but they all use HTTP and HTML. Java, flash, php, etc. are all things that evolved to work along side html as the needs arose. I imagine an analogous pattern will manifest with currency. Developers will come up with new client features that we can’t even imagine yet. People will find uses for currency in places we never dreamed of. Did Tim Berners-Lee fully anticipate how much was going to come from http and html? Probably not. A tidal wave of innovation was unleashed by the openness of the web. Similar innovation will be unleashed by openness of a currency protocol.


So, Cyclos could become more open by adopting these open protocols, enabling it to communicate with ANY other client using the protocol. It would also be more open if it allowed users to create their own currencies rather than depend on administrators to do so.


I hope this clarifies.

4 comments:

marc tirel said...

It does !!
Thanks for this great post

herestomwiththeweather said...

Thankyou for this post. I've read it twice and I don't think I fully understand but it seems there are two fundamentals to the metacurrency proposal:

1. Open source systems like Cyclos should accept identifiers that are part of an identity commons like OpenID

2. Open source systems like Cyclos should support a simple common protocol to allow people to easily create new currency games

#2 is the one that is not obvious. it is not clear to me why we need a common protocol for creating currency games because games are created with programming languages, not protocols.

Alan Rosenblith said...

Tom,
As I understand it, http is the protocol, and html is the language. So the MetaCurrency project is working on MCP (metacurrency protocol) and XGFL (extensible game format language). That latter is a common language that a client reads, so it can understand the rules of a given game, just as html allows a browser to display a hypertext.

Another key point is that ANYONE using a given currency should have access to the same power of currency creation as the admins. Right now, ANYONE can post a blog. We don't have to ask permission from an admin to create a new blog. We just do it and hope that people find it interesting enough to read. Same thing with creating new currencies. This open ability will drive innovation.

Access to the network means access to the ability to create currency games.

I think we will definitely need applications with good UIs to make maximum use of capacity. Think of what iWeb or Dreamweaver did for people wanting to create their own websites.

I hope this helps.

Eric Harris-Braun said...

Alan you are right on in describing this using the HTML/HTTP analogy. I'll just expand a little. You can think of HTML as a rubric, or a framework, that can describe arbitrary information resources, and HTTP as a process for accessing those resources as described using the framework.

In the MetaCurrency project we similarly have a framework for describes arbitrary games (eXtensible Game Format Language: XGFL), and process for making plays in those games (MetaCurrency protocol: MCP) Just as HTML itself can encapsulate what I like to call Turring Power (or programs), like Javascript and Flash, XGFL similarly has structures on which to hang the programs that actually make currencies do what they do.

The point of having both MCP and XGFL is to make it possible to separate out the functions of making transactions (the currency transport layer), and specifying currencies (the currency rules layer). Separating these two concerns is part of ensuring an open network. If there is a transport layer that anybody can access both as a player and as a currency designer, then we've pushed the intelligence to the edges.

As Alan describes, one of the kinds of "open" that this is, is a structural opening of possibilities. Making this separation opens up the space for people to create all kinds of cool new currencies, without the burden of creating a transport network to carry transactions. It also opens up the space for people to create all kinds of cool new applications that make managing your currency accounts more and more easy and useful (think of the evolution of web-browsers, how they've added all kinds of smarts on top of the process of viewing HTML resources, like bookmarks, and history, and tabs, etc).