The "leave" portion of the protocol strikes me as unrealistic. Typically, when a node leaves a network it does so without warning and doesn't have tie to copy its data back. Maybe some level of redundancy will be discussed in the followup.
For particular DHT, namely Chord, a node has f successor list where it stores the replicas of data on each f successors. After failure of a node, the data is stored in its successor list. However, this introduces more overhead to the system, after breakdown find successors and replicate date, and stabilize function should check every successor-list to find inconsistent links. Some other DHTs use interval based division, divide the nodes into fixed intervals and all the nodes in one interval store the data in all other nodes in that interval.
I would think one would dedicate N*2 nodes for a dataset N and just copy the data in any given node to its closest neighbor node. If the lookup for the primary node fails, try its closest neighbor, and if you really want to get snazzy then have that failover neighbor start to copy data to its closest neighbor until you get a replacement node up. A failover daemon on each node will detect when a neighbor goes down and block writes to a copy of data until it's sure the neighbor is down, and won't accept new copies until both it detects the neighbor is back up and has resolved time-based differences in datasets. Probably not foolproof but it's a start :)
I think an interesting follow-up to this since it's now 8 years old, would be an article on setting up DHTs in the cloud, like on Amazon's EC2. As demand for the database/application goes up, rolling additional nodes in real-time would be pretty snazzy. It would 'seem' to me that most use cases need a redundancy level of 3 per location, and then spread across three locations. The capital costs of physical equipment, racking, zoning within a facility for redundant power etc. make a cloud solution much more interesting for 99% of use cases.
