Skip to content

Conversation

@raulk
Copy link
Member

@raulk raulk commented Sep 25, 2020

This introduces editorial changes on top of #294. We now concentrate all our additions in pubsub.md.


@protolambda, I wanted to target your branch, but it's in a fork.

cc @arnetheduck

@raulk raulk requested review from protolambda and vyzo September 25, 2020 14:53
Copy link
Contributor

@protolambda protolambda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, and thanks for making the necessary changes @raulk

Copy link
Contributor

@vyzo vyzo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good; some minor comments, probably worth addressing.

@raulk
Copy link
Member Author

raulk commented Sep 29, 2020

@vyzo all comments addressed. Was your review an approval, subject to the edits you suggested? Or do you want to do another full review?

@raulk raulk requested a review from vyzo September 29, 2020 14:28
authorship is preserved.

The `seqno` field (optional) is a 64-bit big-endian uint that is a linearly
increasing number that is unique among messages originating from each given
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

afair rust-libp2p puts a random number here? is linearly increasing a "hard" requirement?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not really, it just has to be unique within the time cache window.

**Signature verification.** There are two configurations possible:

* `Strict`: either expect or not expect a signature.
* `Lax` (legacy, insecure, underterministic, to be deprecated): accept a signed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to export some of this language to a separate section which simply says that all fields that are set must be valid for their type - seqno must be 8 bytes, if the signature is set it must be valid - these would be pre-conditions to even consider the message for propagation before the "modes" are considered - the "lax" vs "strict" distinction then becomes a requirement for a signature or not.

Copy link
Member Author

@raulk raulk Sep 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, that would be a welcome improvement. All protobuf types are bytes and strings, which express no constraints in and of themselves.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mind submitting a PR against master when this lands (i.e. now)?

@raulk raulk merged commit 40f2048 into master Sep 30, 2020
@raulk raulk deleted the signing-policy-review branch September 30, 2020 09:54
jxs pushed a commit to jxs/specs that referenced this pull request Aug 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants