<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>An optimized conflict-free replicated set · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/1210.3368/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/1210.3368/feed.xml" rel="self" type="application/rss+xml" /><item><title>An optimized conflict-free replicated set — mentioned by cmeiklejohn</title><link>https://news.ycombinator.com/item?id=8066669</link><guid isPermaLink="false">urn:hackerpapers:mention:1210.3368:8066669</guid><pubDate>Mon, 21 Jul 2014 23:39:12 GMT</pubDate><description>&lt;p&gt;Full disclosure: I’m a current employee of Basho Technologies. Other than some supporting work [1] [2] introduced into 2.0 to provide advanced causality tracking, you’re correct in assuming we could have introduced more [3] CRDTs as part of the Riak 1.x series. We could have also implemented all of the CRDTs we provide in the client as well, which is similar to what the SwiftCloud CRDT reference platform does. There&amp;#x27;s a couple important things to note here, however: * When talking about merging conflicting writes, we are specifically referring to state-based CRDTs, not operation-based, which…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1210.3368/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.DC</category></item></channel></rss>
