Hello,
Amir an I have been having a private email conversion about the
Obelisk server, but this information should probably go on the mailing
list as well.

My company, AirBitz is getting close to releasing our wallet to the
general public. Once this happens, will have a huge number of clients
expecting hard binary compatibility with the current obelisk protocol
(as of obelisk commit 7768117901). We can't count on these clients
upgrading, so we need to come up with a plan for future compatibility.

One solution is to introduce explicit versioning into the protocol.
When clients first connect, they send a "version" command, which the
server replies to with a "major.minor" version number. Each time we
add a new command, we bump the minor version, and each time we remove
or change a command, we bump the major version number.

The other solution is to freeze the obelisk protocol and never change
it again except in backwards-compatible ways. Most internet protocols
take this approach, which is why the internet works as well as it
does. We have lots of old, creaky protocols like HTTP and SMTP that
would be nice to "clean up", but the benefits of compatibility
outweigh the costs of upgrading. To enable this approach, we should at
least have the server return an "I don't understand that" message each
time the client sends an unsupported request.

I should also mention that there are plans floating around to replace
"obelisk" with an entirely new "libbitcoin-server" project. This give
us an opportunity to create a clean break with the existing protocol,
so we don't need to get things perfect the first time. This is also an
argument in favor of just freezing the existing protocol, and only
making backwards-compatible additions.

Whichever way we go, we need to make a decision soon (within the next
week or so). We are about to go into feature-freeze, and this issue
only just came up [1].

-William

[1] As it turns out, the current "protocol.broadcast_transaction"
command isn't really reliable. To make it reliable, we need to change
semantics a bit. The question is, do we stuff new behavior into the
existing "protocol.broadcast_transaction", or do we add a new command,
"node.push_transaction"? How we resolve the versioning issue will
determine how we approach this problem.