Implementation

Bitpub in its core is a distributed hash table (DHT). There are already a few widely used DHT protocols. However we have not found any protocols using social network structure to optimize and enhance the DHT. We will explore in this direction.

##Author ID ID is identity of an author. We can use the exactly same way of generating bitcoin address to generate ID.

##Drops The messages published by user on bitpub are called drops. (Along this line discussion can be called rivers and bitpub can be called ocean).

The field contained in each drop is defined as the following.

1. Author ID (20 byte)
2. Digital signature of content hash(70 byte)
3. Content

Content has the following fields:

1. size of the rest of the content
2. Creation time - This field is not used as the absolute time stamp but rather an easy to use time claimed by the author
3. related drops - a dictionary of IDs of related drops and type of the relation.
4. data type (like txt, html, zip) - tells how to process the data.
5. data

The related drops field connect the drop with other drops. The ID of a drop is the hash value of the whole drop. The following field is mandatory for all drops "previous drops of the author" - at most 5 drops(?), maybe use Fibonacci number(?), say the previous 3 drops plus the 5th and 8th. I don't know whether this make sense, but I just feel that it is better than simple store the previous 5 - this information helps to build a time line of the author

If the data is very big one can choose to split into multiple drops to facilitate transmission.In this case the follow types are mandatory: "previous part", "next part" and "first part" - similar as "previous drops of the author" maybe store up to 5 drops' ID. "first part" can be used to test whether two drops belong to the same file. The following are optional "parts index" - a drop which includes list of ID of drops of all parts, like the torrent file in bittorrent protocol.

If the drop is in reply to other drop then the following fields are mandatory. "comment" - the drop it directly comments. "root" - the root drop of the comment. It can be used to check whether two drops belong to the same discussion.

If the drop is a revision to a previous drop then the following fields are mandatory "previous version" "first version" - It can be used to check whether two drops belong to the same file revision.

If the drop cites or mentions other drops the IDs of those drops should listed as "reference" type.