Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(connections): clarify state management around supported protocols #530

Merged
merged 1 commit into from
Mar 23, 2023

Conversation

thomaseizinger
Copy link
Contributor

Resolves #525.

Copy link
Member

@mxinden mxinden left a comment

Choose a reason for hiding this comment

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

Thank you @thomaseizinger for taking this from a rust-libp2p discussion to a libp2p/specs discussion to a libp2p/specs pull request and in the future to a rust-libp2p pull request.

Will leave some time for others to comment before merging.

physical connection to a peer. It MAY only support a protocol based on properties
of a physical connection to e.g. limit the use of bandwidth-heavy protocols over
a relayed or metered connection. A libp2p node MAY offer different sets of protocols
to different peers. It MAY revoke or add the support for a protocol at any time,
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe say that when that happens, it should warn us with an identify push?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am not sure. This section of the specs is pretty ambivalent about protocols. Do we really want to introduce this here?

I like the idea but I think it would be better added to the identify spec rather than here.

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.

Clarify expectations about supported protocols across connections and peers
4 participants