PigeonProtocolConsortium/Protocol-Spec
PigeonProtocolConsortium
/
Protocol-Spec
5
4
Fork 1
Code Issues Pull Requests Releases Wiki Activity

Doc updates.

This commit is contained in:
Netscape Navigator 2020-11-08 15:26:42 -06:00
parent a4a80f9b94
commit 7a45cc7bbd
2 changed files with 6 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -13,7 +13,7 @@ entirely offline.
- [How does the Pigeon protocol benefit users?](#how-does-the-pigeon-protocol-benefit-users) - [How does the Pigeon protocol benefit users?](#how-does-the-pigeon-protocol-benefit-users)
- [Data is backed up by default](#data-is-backed-up-by-default) - [Data is backed up by default](#data-is-backed-up-by-default)
- [Data can be shared anywhere](#data-can-be-shared-anywhere) - [Data can be shared anywhere](#data-can-be-shared-anywhere)
- [Data is tamper-proof](#data-is-tamper-proof) - [Data is tamper-resistant](#data-is-tamper-resistant)
- [Data is always available](#data-is-always-available) - [Data is always available](#data-is-always-available)
- [Use-case scenarios](#use-case-scenarios) - [Use-case scenarios](#use-case-scenarios)
- [Software implementation ideas](#software-implementation-ideas) - [Software implementation ideas](#software-implementation-ideas)
@ -53,7 +53,7 @@ This section consists of the following subsections:
- [Data is backed up by default](#data-is-backed-up-by-default) - [Data is backed up by default](#data-is-backed-up-by-default)
- [Data can be shared anywhere](#data-can-be-shared-anywhere) - [Data can be shared anywhere](#data-can-be-shared-anywhere)
- [Data is tamper-proof](#data-is-tamper-proof) - [Data is tamper-resistant](#data-is-tamper-resistant)
- [Data is always available](#data-is-always-available) - [Data is always available](#data-is-always-available)
## Data is backed up by default ## Data is backed up by default
@ -69,7 +69,7 @@ Every user in the mesh has a local database. You can share your
database entries anywhere, such as CD-R, email, public forums, and database entries anywhere, such as CD-R, email, public forums, and
[USB dead drops](https://en.wikipedia.org/wiki/USB_dead_drop). [USB dead drops](https://en.wikipedia.org/wiki/USB_dead_drop).
## Data is tamper-proof ## Data is tamper-resistant
Entries in the database are cryptographically signed. Because the Entries in the database are cryptographically signed. Because the
entries are signed, you don't have to worry about malicious third entries are signed, you don't have to worry about malicious third

13
dev_docs.md
View File

@ -14,7 +14,7 @@ Pigeon has many of the same goals as Secure Scuttlebutt, including the user's ri
# Fundamental Concept: Content Addressing # Fundamental Concept: Content Addressing
Pigeon Protocol relies heavily on content addressing and the SHA-512 hashing algorithm. This means that instead of assigning arbitrary or user-generated names to resources (as is the case with web addresses), names are assigned using the SHA-512 hash algorithm. Pigeon Protocol relies heavily on content addressing and the SHA-256 hashing algorithm. This means that instead of assigning arbitrary or user-generated names to resources (as is the case with web addresses), names are assigned using the SHA-256 hash algorithm.
Please watch [this video] if you are unfamiliar with hashing algorithms. Please watch [this video] if you are unfamiliar with hashing algorithms.
@ -112,19 +112,12 @@ A peer can use the file above to update their local database. It is important to
* Since Peer A cannot verify message at `depth 8` until it receives `depth 7` and `depth 6`, the messages are rejected by peer A. * Since Peer A cannot verify message at `depth 8` until it receives `depth 7` and `depth 6`, the messages are rejected by peer A.
* Clients always reject messages that cannot be verified. For example, if a `messages.pgn` file starts at `depth 6` for a peer `USER.ABC`, and the local client has only verified `USER.ABC`s feed up to `depth 3`, the messages in the bundle will be rejected by the local client because it does not have enough information available to verify the authenticity of the message. * Clients always reject messages that cannot be verified. For example, if a `messages.pgn` file starts at `depth 6` for a peer `USER.ABC`, and the local client has only verified `USER.ABC`s feed up to `depth 3`, the messages in the bundle will be rejected by the local client because it does not have enough information available to verify the authenticity of the message.
* Messages must be ordered `depth` for a particular author. * Messages must be ordered by `depth` for a particular author.
# Where Do Files Go in a Bundle? # Where Do Files Go in a Bundle?
**UPDATE 17 OCT 2020:** After some review, I realize that the way files were included in bundles does not make sense:
* Deeply nested directory structures were hard to implement and maintain.
* Forcing the _sender_ to state a file's content hash does not make sense from a security or performance perspective.
* Even if the _sender_ states a file's hash, the reciever is still required to verify the hash- why bother?
Files ("blobs") are transferred alongside the `*.pgn` message bundle. Files ("blobs") are transferred alongside the `*.pgn` message bundle.
It is the responsibility of the _receiver_ (not the sender) to calculate the multihash of an incoming file. It is the responsibility of the _receiver_ (not the sender) to calculate the multihash of an incoming file. The ensures that files are not misrepresented or tampered with.
Files added to a blob must follow these naming rules: Files added to a blob must follow these naming rules: