-
Notifications
You must be signed in to change notification settings - Fork 11
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
README.md: Mark ls
as optional
#22
Conversation
go-multistream removed `ls` support in multiformats/go-multistream#76. This breaks compatibility with the multistream implementation in Rust see libp2p/rust-libp2p#2925. This commit updates the specification after the fact, explicitly making `ls` support optional.
@@ -139,6 +139,8 @@ For example | |||
< ... | |||
``` | |||
|
|||
Note that `ls` support is OPTIONAL, i.e. implementations MAY support sending and/or receiving `ls`. This in turn implies that implementations MUST NOT depend on a remote node supporting `ls`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be at the beginning of this section?
Implementations MAY support "listing" of the available protocols. A list message is simply:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I'd also consider marking it as deprecated, but we can punt that till later)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be at the beginning of this section?
Implementations MAY support "listing" of the available protocols. A list message is simply:
Sounds good. Added via 94f37ea.
(I'd also consider marking it as deprecated, but we can punt that till later)
I am fine with deprecating ls
. I don't feel strongly enough about it to push that effort forward though. Let me know in case you do.
swift-libp2p will respond to an |
Smoldot never sends an "ls" request, so not a breaking change. |
Available in nim-libp2p, but not used internally nor by any project afaict |
@@ -139,6 +139,8 @@ For example | |||
< ... | |||
``` | |||
|
|||
Note that `ls` support is OPTIONAL, i.e. implementations MAY support sending and/or receiving `ls`. This in turn implies that implementations MUST NOT depend on a remote node supporting `ls`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I'd also consider marking it as deprecated, but we can punt that till later)
Merging here. Thanks everyone for the input. |
go-multistream removed
ls
support in multiformats/go-multistream#76. This breaks compatibility with the multistream implementation in Rust see libp2p/rust-libp2p#2925.I suggest doing this change, namely updating the specification after the fact, explicitly making
ls
support optional.@Menduist is this a breaking change for nim-libp2p?
@Nashatyrev is this a breaking change for jvm-libp2p?
@kamilsa is this a breaking change for cpp-libp2p?
@btoms20 is this a breaking change for swift-libp2p?
@tomaka is this a breaking change for smoldot?
@MarcoPolo is this a breaking change for zig-libp2p?