> On 18 Oct 2014, at 01:17 , Jens Alfke <[email protected]> wrote: > > >> On Oct 17, 2014, at 2:22 PM, Brian Mitchell <[email protected]> >> 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.
