+Public objects are not included in ``shared`` and ``others`` listings. It is suggested that they are marked in a visually distinctive way in ``pithos`` listings (for example using an icon overlay).
+
+A special application menu, or a section in application preferences, should be devoted to managing groups (the ``groups`` element). All group-related actions are implemented at the account level.
+
+Browsing past versions of objects should be available both at the object and the container level. At the object level, a list of past versions can be included in the screen showing details or more information on the object (metadata, permissions, etc.). At the container level, it is suggested that clients use a ``history`` element, which presents to the user a read-only, time-variable view of ``pithos`` contents. This can be accomplished via the ``until`` parameter in listings. Optionally, ``history`` may include ``trash``.
+
+Uploading and downloading data
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+By using hashmaps to upload and download objects the corresponding operations can complete much faster.
+
+In the case of an upload, only the missing blocks will be submitted to the server:
+
+* Calculate the hash value for each block of the object to be uploaded. Use the hash algorithm and block size of the destination container.
+* Send a hashmap ``PUT`` request for the object.
+
+ * Server responds with status ``201`` (Created):
+
+ * Blocks are already on the server. The object has been created. Done.
+
+ * Server responds with status ``409`` (Conflict):
+
+ * Server's response body contains the hashes of the blocks that do not exist on the server.
+ * For each hash value in the server's response (or all hashes together):
+
+ * Send a ``POST`` request to the destination container with the corresponding data.
+
+* Repeat hashmap ``PUT``. Fail if the server's response is not ``201``.
+
+Consulting hashmaps when downloading allows for resuming partially transferred objects. The client should retrieve the hashmap from the server and compare it with the hashmap computed from the respective local file. Any missing parts can be downloaded with ``GET`` requests with the additional ``Range`` header.
+
+Syncing
+^^^^^^^
+
+Consider the following algorithm for synchronizing a local folder with the server. The "state" is the complete object listing, with the corresponding attributes.
+
+::
+
+ L: local state (stored state from last sync with the server)
+ C: current state (state computed right before sync)
+ S: server state
+
+ if C == L:
+ # No local changes
+ if S == L:
+ # No remote changes, nothing to do
+ else:
+ # Update local state to match that of the server
+ L = S
+ else:
+ # We have local changes
+ if S == L:
+ # No remote changes, update the server
+ S = C
+ L = S
+ else:
+ # Both we and server have changes
+ if C == S:
+ # We were lucky, we did the same change
+ L = S
+ else:
+ # We have conflicting changes
+ resolve conflict
+
+Notes:
+
+* States represent file hashes (either MD5 or Merkle). Deleted or non-existing files are assumed to have a magic hash (e.g. empty string).
+* Updating a state (either local or remote) implies downloading, uploading or deleting the appropriate file.