Mailing-List: contact replication-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: replication@couchdb.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
Subject: Re: rev hash stability
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: <7DABE635-6957-4DD4-AACC-FA1611CCC5F8@couchbase.com>
Date: Sun, 19 Oct 2014 19:49:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <EB5357A1-5059-4DF6-A323-1464CB8AE987@apache.org>
References: 
 <CAEyAqDutRVvWMZt-Ft0mTzP2dNTXsxodHQpEzg=871YMJwB=+A@mail.gmail.com>
 <CAHdjipJojc72U+erZ4p7dPL7V9uHHQwAy91GfCTMGXsMb8tTzQ@mail.gmail.com>
 <CAD2UGCUxMXddEp+hw+yTEe_6kKnn4PpT-5uCf0ekN_NGJ=FH_g@mail.gmail.com>
 <2A340820-EB86-426A-8D41-85E5E0695570@standardanalytics.io>
 <4B97E034-432F-426B-A0D1-7264DEEC7045@couchbase.com>
 <D7FF1C7E-C45B-4DFF-8C6C-F4E2BB7C9B73@standardanalytics.io>
 <CAEyAqDudh_T3wxQm6a7Df17xMxdtCCe3-xTb849f_B9DLK2ekg@mail.gmail.com>
 <D74B2319-A9C1-4291-ACC6-C1128C806E9A@standardanalytics.io>
 <7DABE635-6957-4DD4-AACC-FA1611CCC5F8@couchbase.com>
To: replication@couchdb.apache.org


> On 18 Oct 2014, at 01:17 , Jens Alfke <jens@couchbase.com> wrote:
>=20
>=20
>> On Oct 17, 2014, at 2:22 PM, Brian Mitchell =
<brian@standardanalytics.io> wrote:
>>=20
>> Giving revs meaning outside of this scope is likely to bring up more =
meta
>> discussion about the CouchDB data model and a long history of
>> undocumented choices which only manifest in the particular
>> implementation we have today.
>=20
> That does appear to be a danger. I'm not interested in bike-shedding; =
if the Apache CouchDB community can't make progress on this issue then =
we can discuss it elsewhere to come up with solutions. I can't speak for =
Chris, but I'm here as a courtesy and because I believe interoperability =
is important. But I believe making progress is more important.

+1000. I think so far we=E2=80=99ve had a brief chatter about this and =
we are ready to move on.

How does moving this to a strawperson proposal sound? E.g. have a =
ticket, or pad, or gist somewhere where we can hammer out the details of =
this and what the various trade-offs of open decisions are?

JIRA obviously preferred, but happy to start this elsewhere if it =
provides less friction.

Best
Jan
--


> Back to the matter at hand: experience from a long line of P2P systems =
(from FreeNet onwards) shows the value of giving pieces of distributed =
content their own unique and unforgeable IDs. CouchDB-style revision IDs =
partly meet this need, except that:
> (a) there are interoperability issues because every implementation has =
its own algorithm for generating the IDs;
> (b) none of the current ones are very unforgeable because they use the =
broken MD5 hash instead of something like SHA256;
> (c) the unforgeability isn't verified because the replicator doesn't =
check that a revision's ID matches its contents.
>=20
> At some point =E2=80=94 Couchbase would like to build P2P systems in =
the future =E2=80=94 we may need to take this more seriously, at which =
point it becomes necessary to have a canonical rev-ID generation =
algorithm which is enforced by the replicator. That algorithm will need =
to be standardized for interoperability purposes, since otherwise two =
implementations would reject each other's revisions as forgeries.
>=20
> That's why I see this issue as important.