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)
- [Data is backed up by default](#data-is-backed-up-by-default)
- [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)
- [Use-case scenarios](#use-case-scenarios)
- [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 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 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
[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 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
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.
@ -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.
* 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?
**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.
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: