Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0

[Timothy Brownawell]

On Mon, 2009-08-24 at 21:17 -0400, address@hidden wrote:
> So this time around we're stuck.  Well, not entirely.  I suppose it *is* 
> possible for a development group to upgrade all their clients first...  
> And I suppose we could leave a monotone server that serves the 
> new-protocol monotone source code running on the old protocol so that 
> people are capable of upgrading.
> 
> But could we install negotiation in the new protocol we're introducing 
> now so that next time around we have a chance of avoiding this mess?  
> There will be even more monotone users out there by then.  I don't think 
> we want monotone to end up like gnutella, which treats the use of an 
> obsolete client as an attack.
> 
> That's something I learned years back when I was implementing OSI 
> protocols.  Always negotiate the protocol version.

I guess there are really 2 kinds of protocol changes we make:
  1) The actual data structures (certs, revisions, keys) change.
     This would be like 'changesetify', or the current change,
     or (probably) probably moving to SHA-3.
  2) Only the network part changes.
     This would be moving to SSL, or changing how refinement works.

In case (2) negotiation could be possible, but not in case (1).

We know there's an instance of case (1) coming up in about 3 years
(SHA-3), which will probably require a flag day (and a full history
rebuild).

Before that, there's moving to SSL. This is case (2), so we could try to
add negotiation now to support it. Or we could make it possible for one
server to serve both SSL and non-SSL at the same time on different
ports, and not risk mucking up the nice encryption properties.

I'd prefer to plan for the "different ports" solution for next time,
just because we're mucking around with the cryptography and want the
final result to be nice and clean at that level. That next time should
have plenty of planning, and we can come up with a decent negotiation
scheme (which we very well might not get a chance to use before SHA-3
comes out :) ).

We'll also need to figure out how long to maintain compatibility for in
the case of type (2) changes, even though this probably won't be an
issue until after SHA-3 (unless we decide to allow for mixed hash types
in your history or something, seems vaguely dangerous). Perhaps we also
want to limit 'db migrate' compatibility to the same time span?