diff --git a/docs/old-design.rst b/docs/old-design.rst
new file mode 100644
index 0000000..4c9ef8f
--- /dev/null
+++ b/docs/old-design.rst
@@ -0,0 +1,187 @@
+Design Document (Obsolete)
+==========================
+
+
+Leaves
+------
+
+Leaf Node
+~~~~~~~~~
+
+``Leaf`` is the base class which contains NameInfo and SeqNo.
+
+NameInfo
+++++++++
+
+``NameInfo`` is an abstract class and has only one implementation class ``StdNameInfo``.
+Name is managed as a string in ``StdNameInfo``.
+
+``StdNameInfo`` also maintains an internal table of all created ``StdNameInfo`` objects.
+(**NOT CLEAR WHY**)
+
+SeqNo
++++++
+
+``SeqNo`` contains two pieces of information ``m_session`` and ``m_seq``.
+
+``m_session`` (uint64) is Session ID (e.g., after crash, application will choose new session ID.
+Session IDs for the same name should always increase.
+
+``m_seq`` (uint64) is Sequence Number for a session.
+It always starts with 0 and goes to max value.
+(**For now, wrapping sequence number after max to zero is not supported**)
+
+``SeqNo`` also contains a member ``m_valid``.
+It seems that ``SeqNo`` is "invalid" if ``m_seq`` is zero.
+
+Full Leaf Node
+~~~~~~~~~~~~~~
+
+``FullLeaf`` inherits from ``Leaf``.
+Compared to ``Leaf``, ``FullLeaf`` can calculate digest of a leaf.
+
+Digest is calculated as ``H(H(name)|H(session|seq))``.
+
+Diff Leaf Node
+~~~~~~~~~~~~~~
+
+``DiffLeaf`` inherits from ``Leaf``.
+Compared to ``Leaf``, ``DiffLeaf`` contains information about operation: Update & Remove.
+
+
+State (Tree)
+------------
+
+State
+~~~~~
+
+``State`` is an abstract class of digest tree.
+This class defines two methods ``update`` and ``remove``.
+It has only one implementation class ``FullState``.
+
+FullState
+~~~~~~~~~
+
+``FullState`` implements the interface defined by ``State`` and also support digest calculation.
+Digest is calculated as:
+
+0. If the tree is empty, the digest is directly set to ``00``.
+1. Sort all leaves according to names (in std::string order, see std::string::compare).
+2. ``H(H(l1)|H(l2)|...|H(ln))``
+
+
+
+``FullState`` also records the timestamp of the last update.
+
+DiffState
+~~~~~~~~~
+
+``DiffState`` can be considered as a "commitment", which includes a set of ``DiffLeaves``.
+``DiffState`` is maintained as a list.
+Each ``DiffState`` object has a pointer to the next diff.
+Each ``DiffState`` object also has a digest which corresponds to its full state.
+
+
+SyncLogic
+---------
+
+``SyncLogic`` is the core class of ChronoSync.
+
+Initialization
+~~~~~~~~~~~~~~
+
+``SyncLogic`` requires a ``m_syncPrefix``, a callback ``m_onUpdate`` to handle notification of state update, and a callback ``m_onRemove`` to handle notification of leaf removal.
+
+When created, ``SyncLogic`` will listen to ``m_syncPrefix`` to receive sync interest.
+A ``m_syncInterestTable`` is created to hold incoming sync interest with the same state digest as the receiving instance.
+
+``SyncLogic`` also has a ``m_perBranch`` boolean member and a ``m_onUpdateBranch`` callback member.
+(**NOT CLEAR ABOUT THE USAGE**. It seems that if ``m_perBranch`` is set, ``m_onUpdateBranch`` will be called, but ``m_onRemove`` and ``m_onUpdate`` will not be called.)
+
+Working Flow (onData)
+~~~~~~~~~~~~~~~~~~~~~
+
+``SyncLogic`` periodically expresses sync interest which contains its own state digest.
+Sync interest is constructed by concatenating the ``m_syncPrefix`` with the hex-encoded state digest.
+The ``MustBeFresh`` field of the sync interest must be set.
+When a sync interest is sent out, a timer is set up to re-express sync interest.
+The value of timer is set to ``4,000,000 + rand(100, 500)`` milliseconds.
+
+Sync interest is associated with two callbacks: ``onSyncData`` and ``onSyncTimeout``.
+``onSyncTimeout`` does nothing, because interest re-expressing is handled by a scheculer.
+``onSyncData`` validates the data. Invalid data will be dropped.
+If data can be validated, the packet will go through following process:
+
+1. ``SyncLogic`` deletes interests in ``m_syncInterestTable`` which can be satisfied by the sync data, because these interests
+in ``m_syncInterestTable`` must have been satisfied before the data packet is received.
+
+2. ``SyncLogic`` decodes the sync data into a ``DiffState`` object. ``DiffLeaves`` in ``DiffState`` is sorted according to name.
+``SyncLogic`` applies each ``DiffLeaf`` in the sorted order. If the operation in ``DiffLeaf`` changes the status, ``SyncLogic``
+will generate its own diff log which is also a ``DiffState`` object. If ``SyncLogic`` detect that the received sync data has some
+information that it is missing, it will prepare a ``MissingDataInfo`` which includes ``prefix`` (name), ``low`` (lowest missing SeqNo),
+and ``high`` (highest missing SeqNo), and call ``m_onUpdate`` on it.
+If the content of sync data cannot be parsed, the packet is dropped.
+
+3. ``SyncLogic`` compares the sync data name with ``m_outstandingInterestName`` which is the name of the outstanding sync interest
+sent by the instance. If so, ``SyncLogic`` expresses new sync interest after sync data processing is done, otherwise does nothing
+
+Working Flow (onInterest)
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+``SyncLogic`` also expects to receive sync interest from others.
+If a sync interest is received, the packet will be processed as following:
+
+1. ``SyncLogic`` checks whether the interest is a normal interest or recovery interest (which will be described later).
+If data is a normal sync data packet, go to Step 2, otherwise go to Step 7.
+
+2. Receiving a normal sync interest, check if its digest is ``00``. If so, go to Step 3, otherwise go to Step 4.
+
+3. Receiving an initial sync interest (sending instance has an empty sync tree). If receiving ``SyncLogic`` 's sync tree is not empty,
+encode the whole sync tree into response (sync data), otherwise both sender and receiver are in the same status, put the interest into
+``m_syncInterestTable``.
+
+4. Receiving a sync interest which contains some state. Check if the sender and receiver are in the same status, if so, put the interest
+into ``m_syncInterestTable``. Otherwise check if sender's state exist in receiver's log, if so, merge all the difference into one
+``DiffState`` and encode it into response (sync data). If the receiver cannot recognize the sender's state, go to Step 5.
+
+5. Check if immediate recovery is needed (whether ``timedProcessing`` is set), if so, express recovery interest immediately (go to Step 6).
+Otherwise check if the interest exist in ``m_syncInterestTable``. If the interest has not been inserted into the table before,
+process the interest again after ``rand(200, 100)`` milliseconds but with ``timedProcessing set``. If the interest exist in the table,
+insert it again simply refreshes the table and defers the interest processing for another random period. It is guaranteed that a recovery
+interest will be sent out when the interest is processed again.
+
+6. Send recovery interest. A recovery interest is constructed by inserting a name component ``recovery`` between the ``m_syncPrefix`` and
+the received digest. Default recovery interest re-expressing timer is 200 milliseconds with a jitter ``rand(100, 500)`` milliseconds.
+Every time when recovery interest times out, the timer will be doubled until is longer than 100 seconds.
+
+7. Receiving a recovery sync interest, check if its digest is recongized. If not, drop the interest, otherwise, encode the sync tree in the
+response.
+
+Name Publishing
+~~~~~~~~~~~~~~~
+
+``addLocalName`` method is used to update leaf nodes.
+Caller needs to supply prefix (name), session, and seq.
+The 3-tuple will trigger state changes and sync interest/data exchange.
+
+Data Validation (in paper, not implemented)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Each leaf as a sibling for endorsement.
+The name of the sibling is constructed by concatenating the original leaf's name with a name component ``ENDORSE``.
+``SyncLogic``, when parsing the returned data, will automatically fetch & process ``ENDORSE`` data.
+
+Unresolved Issue
+~~~~~~~~~~~~~~~~
+
+1. Remove leaf
+
+2. SeqNo wrapp-up
+
+SyncSocket
+----------
+
+``SyncSocket`` is a wrapper of ``SyncLogic``. It can be viewed as an interface to a leaf node.
+Through SyncSocket, user only needs to publish its data.
+``SyncSocket`` will maitain corresponding sequence number, and trigger synchronization throug ``SyncLogic::addLocalName`` method.
+``SyncSocket`` is also responsible for actual data publishing.