Most of the open standards we use are not licensed for remixing. That is, if you take the HTTP spec and try to make a new document based off it, and publish that, you are violating the IETF's copyright, and your modified spec will (I assume) be asked to disappear.

In the old days, the thinking was that a standard has to be inviolate. There's a process for building it, and then we need a single standard. Forking a standard would be… bad.

Then around 2007 we realized that if a standard ever became important (in a good or bad way) to someone's business, it was relatively easy for powerful, wealthy firms to simply take over the standards-making body, and thus take over the standards. We saw this happen with OOXML, where Microsoft effectively took over parts of ISO so it could push this thing through as an "International Standard". Microsoft then did a similar move into OASIS so it could control the future of ODF, the competing standard.

Anyone involved in standards-setting committees has seen the cost of the traditional process. The key question we had in Digistan was how do we make standards development cheaper? I used the term "unprotocol" to describe this cheap, community-built standard.

Of course anyone can design and publish a protocol and say, "He guys, here's my vision, any comments?" How do you get real contributions from people willing to bet money on that?

I argued at the time that developing standards was the same as writing software. You want people to compete and collaborate in the same way. Open knowledge. Blah blah, you know the story. My main argument was that forking was not bad, but essential. The right to fork was essential. It's the only guarantee an implementor has that if some unkind people with more time and money capture the standard process, they don't destroy your business. Paranoia? Maybe, but it happened to us with AMQP, which became a captive enterprise jelly fish. We lost a huge investment in OpenAMQ. Well, it freed us to make ZeroMQ but still… that should have happened as a smooth evolution of AMQP, not a reboot.

Freedom to fork. This is the first, essential requirement of an unprotocol. Any open source license will give this freedom, BSD, MIT, X11, Apache, MPL, GPL. Also, a Creative Commons license like CC0.

But it's not sufficient. Imagine if AMQP had been BSD or CC0. Now imagine it's successful and businesses start rolling out products based on it. They're competitors so they look for ways to gain advantage. One classic way is to build proprietary extensions. This happens so often it's ridiculous.

If I'm a lawyer working for some evil corporation, say Microhat, or Redsoft, I'll tell my clients this: "You make an extension of the standard that passes the conformance tests, but you make your extensions proprietary and you license them on your own terms."

If I extend a CC0 or BSD protocol, my version of the protocol is by default proprietary. The license does not extend to forks. I can announce any licensing model I want on my extensions. For instance, "You may only use this protocol on Tuesdays". Now, if I'm big and rich enough, I can force this on my users.

Forks must be remixable. This is the second, essential requirement of an unprotocol. If you don't do this, your low-cost community is vulnerable to attack by well-funded competitors. Only the CC-SA and GPL provide this assurance.

Further, as that lawyer, I tell my clients, "Now please file a patent claim on these extensions and put a patent license into your support model. It doesn't matter if the patent gets granted. The claim will be enough to scare clients into paying."

Paranoia? Maybe, but RedHat did this with AMQP: patented a proprietary extension for XML routing. Patents aren't just toxic to competition, they can scare people away from the whole standard itself.

OK, it's true that anyone can file patents on protocols, but it's the firms that implement them who have the strongest incentive to patent around the edges. You do need to consider this threat.

So, the last requirement is protection from patents. The GPLv3 has language that scares off patent lawyers. It's effective. and arguably the main reason Apple has invested so much in removing all GPLv3 products from its stacks and tool chains.

Finally, how do you enforce interoperability when anyone can make forks? The answer is the same as in open source. You use a domain name and trademark and establish your processes under that brand. For instance, conformance tests, and contribution policy. People see the name, they know what they're getting.

So in conclusion, my advice is to treat protocol licensing like network security. You try to guard against known attacks, you don't trust good intentions. It comes down to CC-BY-SA if you're not concerned about patents, and GPLv3 if you are.

by pieterh

Kelly, those screams you hear from current AMQP adopters aren't the screams of ignorance. Explaining nicely why AMQP/1.0 is so much better, technically, misses the point. Worse, it adds insult to injury. Oh poor AMQP/0.9.1 user, not only are you trapped in a burning house, but it's your fault, for being so bloody ignorant.

The AMQP Working Group built a house, then invited people in for barbecue and free beer, and then deliberately burnt the house down, with the doors locked, because they weren't happy with it.

Passing the buck to OASIS doesn't absolve the AMQP working group of a massive failure. Every single person associated with the AMQP/1.0 release should be, metaphorically, tarred and feathered and banned from ever again participating in a standards effort. Their names should be listed on that sanitized, purged Wikipedia page. AMQP/1.0 will go down in history as a prime documented example of how to fail a standardization effort and hurt a lot of people in the process.

Easy prediction: the screams of anger and pain from the AMQP community are going to get louder as they realize just what's happened. In part this article is a careful, deliberate move because I don't want that anger bouncing back on me and my work. But also, it's an excuse to hit the bullies with a stick, because, karma.

The calculation of the AMQP/1.0 authors, and those who support them, is that the pain inflicted on the AMQP community is worth the benefits. I've written before that large rich firms don't feel pain like normal people. But they're also incredibly selfish and shortsighted.

AMQP/0.9.1 is legally and technically dead. The old spec is copyrighted by the AMQP Working Group and not remixable. There are no mechanisms for extensions, patches, fixes, anything.

AMQP/1.0 is touted as an upgrade for AMQP/0.9.1 when it's not. The two operate at different layers. One is a transport layer, one is a model layer. A healthy stack would swap transport layers over time and keep semantics compatible.

The pain that AMQP/1.0 will cause was entirely avoidable. It was plausible to replace the 0.9.1 transport layer but keep the exchange-binding-queue semantics. Even offer a gradual migration to other semantics. The 1.0 authors just couldn't be bothered. A matter of pride and greed. The house had to go.

95% of the AMQP community has invested in a dead standard. I count 4,528 repositories on GitHub that refer to AMQP. There are 244 that refer to AMQP/1.0. That makes 95% of the community wrong. This isn't marginal.

There is no documented cost/benefit argumentation. The costs of change cannot simply be ignored. There must be argumentation, explanation, justification for what is so wrong with AMQP/0.9.1 that it had to be destroyed.

AMQP/1.0 does not define semantic interoperability. The primary requirement for AMQP (to ensure interoperability between implementations) has been dropped. It's up to each vendor how they do messaging.

AMQP/1.0 is great for big vendors, tragic for users. The only value of a standard is to level the playing field so clients can choose vendors. AMQP/1.0 doesn't level the field, and is barely worth calling a 'standard'.

The whole point of the AMQP/1.0 change was to screw users. I can't believe a determined five-year effort to tilt the playing field against competition was just stupidity. The goal is control over the billion dollar messaging market.

And finally, AMQP cannot survive this event. It's quite simple: AMQP attracted the pioneers, the leading edge. It's these people who invested most in that house that is now burning up.

When we at iMatix quit the working group and shuttered years of work (and really, read the OpenAMQ docs and realize this wasn't a toy project but a massive and sincere effort), it was because we saw the lunatics pouring gasoline, tried and failed to stop them. We described the problems in detail, and we built 0MQ as a safe refuge for anyone who would listen. But the barbecue and free beer continued, pulling in thousands of engineers, some of the best of a generation.

So if you invested in AMQP, like we did, and find that you really don't have much say in the future, what can you do?

Here's my answer: come to the 0MQ community. We also have a peer-to-peer transport protocol but it's kind of simple. We have independent implementations in several languages: C++, Java, Flash, Bash (yes), Node.js, even JavaScript in the browser. The main C++ stack has 40+ language bindings.

You'll find a community that owns what it makes. A community that enjoys itself and rarely argues, because hey, send a patch. A contribution process that is perfectly fair, open to all, and coherent. You'll find that whatever you were trying to do with AMQP you can do with 0MQ, with less stress and more fun. Of course the two technologies aren't the same. One is dead, one is very much alive.

We built 0MQ so that messaging would be fun again. We built 0MQ to kill AMQP/1.0 when it finally emerged, to keep messaging open and free to all, because we believe it's essential. We built 0MQ so that our messaging protocols would never be owned by greedy, selfish fools who treat quarterly profits as more valuable than community. Help us make that happen and teach the bullies a lesson. Because, karma.

by pieterh

First the whole thing:

NOM-1 = open-peering *use-peering open-peering = C:OHAI ( S:OHAI-OK / S:ROTFL ) use-peering = C:OHAI ( S:OHAI-OK / S:ROTFL ) / C:HUGZ S:HUGZ-OK / S:HUGZ C:HUGZ-OK / C:ICANHAZ ( S:ICANHAZ-OK / S:ROTFL ) / S:ICANHAZ ( C:ICANHAZ-OK / C:ROTFL ) / C:NOM / S:NOM ROTFL = version reserved %b0000 %b0000 reason-text version = %b0001 reserved = %b0000 reason-text = *VCHAR OHAI = version reserved %b0001 %b0000 address address = ( broadcast / hostname / hostnumber ) ":" port broadcast = "*" hostname = label *( "." label ) label = 1*( %x61-7A / DIGIT / "-" ) hostnumber = 1*DIGIT "." 1*DIGIT "." 1*DIGIT "." 1*DIGIT port = 1*DIGIT OHAI-OK = version reserved %b0010 %b0000 address HUGZ = version reserved %b0011 %b0000 HUGZ-OK = version reserved %b0100 %b0000 ICANHAZ = version reserved %b0101 sequence zmq-payload ICANHAZ-OK = version reserved %b0110 sequence zmq-payload sequence = 4BIT ; Incrementing for each ICANHAZ zmq-payload = 1*zmq-frame zmq-frame = frame-size frame-body frame-size = 2OCTET ; In network byte order frame-body = *OCTET ; frame-size octets NOM = version reserved %b0111 %b0000 zmq-payload

and now the notes:

• A client opens a peering to a server. A server binds to and receives from some port. "Client" and "server" means exactly which node opens the peering, and which node accepts the peering. Nothing more. A peering has some state. We'll come to that.

• A client may start a peering-open dialog before the server is ready. In this case the client will send OHAIs repeatedly, at short intervals, until a server responds with OHAI-OK.

• The OHAI commands specifies an address, which the OHAI-OK command echoes. This lets a client broadcast OHAI to any listening server, and connect to the one that responds. We call this a broadcast peering.

• Once a peering is established, either peer can send unsolicited HUGZ, ICANHAZ, or NOM commands. A client can also send OHAI more than once to the same server, which may be needed since UDP can lose messages, e.g. the returning OHAI-OK.

• The ICANHAZ/ICANHAZ-OK commands are for the synchronous request-reply pattern (specifically for 0MQ REQ/REP sockets). NOM-1 does not use address envelopes, it is designed for single-hop request-reply.

• Since UDP will randomly drop messages, ICANHAZ implements a minimal resend capability. Each ICANHAZ command has an incrementing sequence number. The sender resends the ICANHAZ at short intervals at least as long as the peering is alive, until it receives a matching ICANHAZ-OK. The recipient will resend its last ICANHAZ-OK if it receives a duplicate request.

• Heartbeating consists of a ping-pong HUGZ/HUGZ-OK dialog. One peer sends HUGZ to the other, which replies with HUGZ-OK. Neither command has any payload. HUGZ and HUGZ-OK are not correlated. A peer should send HUGZ at regular intervals.

• Silence means a peer has died. A server should handle this by destroying all resources associated with that peering. A client should handle this by restarting the peering-open dialog.

by pieterh

NOM-1 provides the basic support for 0MQ socket patterns, over UDP. It's the first in a series of unprotocols I want to build. They all have the same philosophy: to extend the 0MQ transport family with new, unusual, experimental, and hopefully useful protocols.

If you've used UDP you'll know it's quite fun. No connections, you just send to a hostname:port, and if there's someone to catch the ball, a message arrives. If not, it gets dropped. And UDP will drop messages randomly anyhow. And it limits them to about 500 bytes. But it's fast, simple, doesn't do weird stuff behind the scenes.

It turns out that 0MQ and UDP fit together neatly. Like UDP, 0MQ doesn't really have connections. They kind of come and go invisibly. It also drops messages when it gets bored. So, building some simple 0MQ-friendly semantics on top of UDP was fun.

What you get is not like TCP at all. Here is what NOM-1 does already:

• It has a simple framing for commands and messages.
• It allows peers to establish 'peerings' (like connections but with fewer overloaded semantics and letters to type)
• It does heartbeating so that peers can destroy or disconnect peerings rapidly.
• It does broadcast peerings (this is fun, you connect to a host called '*' and the first that replies becomes the endpoint for the peering).
• It does asynchronous message transfer (single parts, no reliability)
• It does peering reconnection as peers go away and come back.

All this is implemented in the VTX UDP driver, which is the reference implementation for NOM-1. I'll probably make a stand-alone stack as a learning tool, because VTX is kind of abstract (thus complex) in itself.

Next up will be basic request-reply retries, needed since UDP randomly drops packets and this'll kill any 0MQ REQ sockets waiting for an answer. It's still not TCP. For example, pub-sub or push-pull will work at full speed without any acknowledgements or retries. Unreliable pipelines? Why not.

My test case is a simple client that does a broadcast connect, sends 'hello?' and waits for a response. The server does a bind, waits for a request, and replies with 'acknowledge'.

Here's the client trace:

ph@ws200901:~/work/vtx/v3 :master$ vtx_testcli 11-06-14 14:11:33 I: create peering=0x25aee30 - 192.168.55.255:32000 11-06-14 14:11:33 C: hello? 11-06-14 14:11:34 I: send [OHAI] - 20 bytes to 192.168.55.255:32000 11-06-14 14:11:35 I: send [OHAI] - 20 bytes to 192.168.55.255:32000 11-06-14 14:11:36 I: send [OHAI] - 20 bytes to 192.168.55.255:32000 11-06-14 14:11:37 I: send [OHAI] - 20 bytes to 192.168.55.255:32000 11-06-14 14:11:38 C: hello? 11-06-14 14:11:38 I: send [OHAI] - 20 bytes to 192.168.55.255:32000 11-06-14 14:11:38 I: recv [OHAI-OK] - 22 bytes from 192.168.55.156:35860 11-06-14 14:11:38 I: rename peering from 192.168.55.255:32000 to 192.168... 11-06-14 14:11:38 I: bring up peering=0x25aee30 11-06-14 14:11:38 I: send [NOM] - 6 bytes to 192.168.55.156:35860 11-06-14 14:11:38 I: send [NOM] - 6 bytes to 192.168.55.156:35860 11-06-14 14:11:38 I: recv [NOM] - 13 bytes from 192.168.55.156:35860 11-06-14 14:11:38 I: recv [NOM] - 13 bytes from 192.168.55.156:35860 11-06-14 14:11:39 C: hello? 11-06-14 14:11:39 I: send [HUGZ] - 0 bytes to 192.168.55.156:35860 11-06-14 14:11:39 I: send [NOM] - 6 bytes to 192.168.55.156:35860 11-06-14 14:11:39 I: recv [HUGZ] - 2 bytes from 192.168.55.156:35860 11-06-14 14:11:39 I: send [HUGZ-OK] - 0 bytes to 192.168.55.156:35860 11-06-14 14:11:39 I: recv [HUGZ-OK] - 2 bytes from 192.168.55.156:35860 11-06-14 14:11:39 I: recv [NOM] - 13 bytes from 192.168.55.156:35860 11-06-14 14:11:40 C: hello? 11-06-14 14:11:40 I: send [NOM] - 6 bytes to 192.168.55.156:35860 11-06-14 14:11:40 I: recv [NOM] - 13 bytes from 192.168.55.156:35860 11-06-14 14:11:41 C: hello? 11-06-14 14:11:41 I: send [NOM] - 6 bytes to 192.168.55.156:35860 11-06-14 14:11:41 I: recv [NOM] - 13 bytes from 192.168.55.156:35860 11-06-14 14:11:42 C: hello? 11-06-14 14:11:42 I: send [NOM] - 6 bytes to 192.168.55.156:35860 ^C11-06-14 14:11:43 I: shutting down driver, 0 errors 11-06-14 14:11:43 I: delete peering=0x25aee30 - 192.168.55.156:35860

And here's the server trace:

ph@ws200901:~/work/vtx/v3 :master$ vtx_testsrv 11-06-14 14:11:38 I: recv [OHAI] - 22 bytes from 192.168.55.156:48680 11-06-14 14:11:38 I: create peering=0xda7f00 - 192.168.55.156:48680 11-06-14 14:11:38 I: send [OHAI-OK] - 20 bytes to 192.168.55.156:48680 11-06-14 14:11:38 I: bring up peering=0xda7f00 11-06-14 14:11:38 I: recv [NOM] - 8 bytes from 192.168.55.156:48680 11-06-14 14:11:38 I: recv [NOM] - 8 bytes from 192.168.55.156:48680 11-06-14 14:11:38 S: acknowledge 11-06-14 14:11:38 I: send [NOM] - 11 bytes to 192.168.55.156:48680 11-06-14 14:11:38 S: acknowledge 11-06-14 14:11:38 I: send [NOM] - 11 bytes to 192.168.55.156:48680 11-06-14 14:11:39 I: send [HUGZ] - 0 bytes to 192.168.55.156:48680 11-06-14 14:11:39 I: recv [HUGZ] - 2 bytes from 192.168.55.156:48680 11-06-14 14:11:39 I: send [HUGZ-OK] - 0 bytes to 192.168.55.156:48680 11-06-14 14:11:39 I: recv [NOM] - 8 bytes from 192.168.55.156:48680 11-06-14 14:11:39 I: recv [HUGZ-OK] - 2 bytes from 192.168.55.156:48680 11-06-14 14:11:39 S: acknowledge 11-06-14 14:11:39 I: send [NOM] - 11 bytes to 192.168.55.156:48680 11-06-14 14:11:40 I: recv [NOM] - 8 bytes from 192.168.55.156:48680 11-06-14 14:11:40 S: acknowledge 11-06-14 14:11:40 I: send [NOM] - 11 bytes to 192.168.55.156:48680 11-06-14 14:11:41 I: recv [NOM] - 8 bytes from 192.168.55.156:48680 11-06-14 14:11:41 S: acknowledge 11-06-14 14:11:41 I: send [NOM] - 11 bytes to 192.168.55.156:48680 ^C11-06-14 14:11:42 I: shutting down driver, 0 errors 11-06-14 14:11:42 I: delete peering=0xda7f00 - 192.168.55.156:48680

I'll have a draft spec up real soon now.

by pieterh

Cheap is a pattern for low-volume chatty dialogs, and Nasty is a pattern for high-volume data flows. Realistic unprotocols often need to combine both chatty dialogs and high-volume data flows, and it's a common mistake — which I'm well aware of, having made it more than once — to try to use a single design to cover both these.

Let's start with Cheap. Cheap is essentially synchronous, verbose, descriptive, and unstable. A Cheap message is full of rich information that changes practically for each application. Your goal as designer is to make this information easy to encode and to parse, trivial to extend for experimentation or growth, and highly robust against change both forwards and backwards. The ideal Cheap pattern looks like this:

• It uses a simple self-describing structured encoding for data, be it XML, JSON, tnetstrings, or some other. Any encoding is fine so long as there are standard simple parsers for it.
• It uses a straight request-reply model where each request has a success/failure reply. This makes it trivial to write correct clients and servers for a Cheap dialog.
• It doesn't try, even marginally, to be fast. Performance doesn't matter when you do something once a minute, or once a second.

A good example of a Cheap protocol would be HTTP. But over ØMQ, you can create a Cheap protocol relatively trivially. A Cheap parser is something you take off the shelf, and throw data at. It shouldn't crash, shouldn't leak memory, should be highly tolerant, and should be relatively simple to work with. That's it.

Now let's look at Nasty. Nasty is essentially asynchronous, terse, silent, and stable. A Nasty message carries minimal information that practically never changes. Your goal as designer is to make this information ultrafast to parse, and possibly even impossible to extend and experiment with. The ideal Nasty pattern looks like this:

• It uses a hand-optimized binary layout for data, where every bit is precisely crafted.
• It uses a pure asynchronous model where one or both peers send data without acknowledgments (or if they do, they use sneaky asynchronous techniques like credit-based flow control).
• It doesn't try, even marginally, to be friendly. Performance is all that matters when you are doing something several million times per second.

A good example of a Nasty protocol would be ØMQ's publish-subscribe protocol, which is so brutally terse that it feels more like a weapon invented by Iain M. Banks than a network protocol. A Nasty parser is something you write by hand, which writes or reads bits, bytes, words, and integers individually and precisely. It rejects anything it doesn't like, does no memory allocations at all, and never crashes.

You'll see people trying to use Cheap everywhere ("everything is an XML message!"), or Nasty for everything ("Our wire level protocol is 100% binary!"). Or, some intermediate solution that is neither Cheap, nor Nasty ("we use protobufs for everything!"). The results will be mediocre. Don't be afraid of going to extremes, when you're writing software that has to be extremely good.

Remember: Cheap for the chatty stuff, Nasty for the real work. Enjoy!

by pieterh

Like good little unprotocols, MDP and TSP are easy to implement. The Majordomo broker in PHP is about 300 lines of code, and the client stack is 150 lines of code.

Majordomo, in case you're using or interested in ØMQ, is a service-oriented protocol that connects a set of clients to a set of service workers. It's basically a shared queue model. Titanic turns Majordomo into a fully async persistent service model. If you think it's hard to do persistent messaging across ØMQ, look at Titanic. It isn't fast (one message per disk file is the KISS implementation) but obviously could be made much faster, using the same protocol and stacks.

Majordomo and Titanic already work in C, and Lua.

Edit: and also here's an independent implementation of Majordomo in Python.

by pieterh

RestTL emerged about two years ago as the lowest layer of a RESTful stack called RestMS. It's a lovely little transport layer, abstract and extensible. We made it (Steve Vinoski, Brad Clements, and myself) after refactoring the earlier RestMS draft into three layers. Here's a common pattern for unprotocols: start quickly, make it work, then refactor into neater and more abstract layers.

by pieterh

On the #zeromq IRC channel, on Saturday 30th April 2011:

Yeah, it actually took two whole hours to scrape this little unprotocol together from a bunch of leftover potato peelings, ØMQ man pages, and my warped imagination.

Presumably it's full of errors, but as the great Digistan says, "specifications should take minutes to explain, hours to design, days to write, weeks to prove, months to become mature, and years to replace."

First person to implement ZMTP in JavaScript wins 1,000 internets. YARLY.

by pieterh

Inspired by and blatantly ripped-off from @monadic / Alexis Richardson's LOLMQ.

Keyword List

The core philosophy of unprotocols is that they should speak the same language as the people who use them. So:

• OHAI - sent by a client to a server when it wants to initiate a dialog.

• ORYL? - sent by a server to a client when it wants to get authentication information such as a password hash.

• YARLY - sent by a client to a server when it wants to authenticate with some information.

• ICANHAZ? - sent by a client to a server, along with some arguments, to request some resource from the server.

• CHEEZBURGER - sent by a server to a client, along with some properties, to indicate a resource delivered from server to client.

• NOM - sent by a client to a server to acknowledge that it's happily received some resource.

• LOL - sent by a client to a server to reject a resource as inedible.

• KITTEH - used in general to indicate a client or server peer. Note: considered rather too cute for srs unprotocols.

• KTHXBAI - sent by a server to a client, or a client to a server, when it finishes some dialog.

• HUGZ - sent by a server to a client, or a client to a server, to indicate that it's still around and not going anywhere just now. Kind of like a keep-alive heartbeat.

• SRSLY? - sent by a server to a client when it refuses some operation due to access rights.

• RTFM - sent by a server to a client that uses an invalid value or argument.

• WTF? - sent by a server to a client when it refuses some operation because it's not meaningful. After a WTF? the client may retry.

• ROTFL - sent by a server to a client when it refuses some operation and disconnects the client for being silly.

• PWNED - sent by a server to a client when it cannot perform some operation due to being pretty much exhausted.

by pieterh

Welcome to unprotocols.org.

Let's take these three essential properties one by one. In 2008 I wrote an analysis for the Digital Standards Organization on the different ways of capturing a standard. It's an amusing way to look at open standards. Instead of listing properties like "Freely available text" and "Patents licensed under reasonable and non-discriminatory terms", the "freedom from capture" approach lets us say that "A standard is a published specification. It is a free and open standard if it is immune to vendor capture at all stages in its life-cycle."

And in real life, standards do get captured, even with the best intentions. The most common is simple copyright. Yes, you can implement this spec. No, you may not mix it into new shapes and forms. For me, a work that can't be remixed isn't culture. At best it's a snapshot of culture. And the best contract for remixing software is the GPL, because it (a) forces anyone who mixes someone's work to reciprocate and allow mixing of their work, and (b) it has clauses to prevent patent hijacks.

So, unprotocols are GPL licensed. Freaky, huh? Yet it works really nicely. Take any of the specs at http://rfc.zeromq.org, and feel free to remix. This is literally how the process works.

OK, part two: lightweight. Again, to quote Digistan.org (I love that website), "Specifications should take minutes to explain, hours to design, days to write, weeks to prove, months to become mature, and years to replace."

If it takes more than a few pages to define a contract, then there's something wrong. Long, complex, tedious contracts usually mean one party is cheating the other. Whereas a conventional protocol spec might be several hundred pages long, the unprotocol equivalent would be a stack of three or four 5-page specs.

Finally, "natural semantics". By this, I mean that an unprotocol should read naturally, use words that are familiar, and be obvious. If it's too complex, it's wrong. In my next posting I'll propose a set of Keywords for Unprotocols that show what I mean.

by pieterh