couchdb-replication mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: rev hash stability
Date Sun, 19 Oct 2014 17:49:22 GMT

> On 18 Oct 2014, at 01:17 , Jens Alfke <jens@couchbase.com> wrote:
> 
> 
>> On Oct 17, 2014, at 2:22 PM, Brian Mitchell <brian@standardanalytics.io> wrote:
>> 
>> 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.
> 
> 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’ve 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.
> 
> At some point — Couchbase would like to build P2P systems in the future — 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.
> 
> That's why I see this issue as important.



Mime
View raw message