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

Add code for SCION multiaddrs #325

Merged
merged 2 commits into from
Jun 9, 2023
Merged

Conversation

leonrinkel
Copy link
Contributor

We'd like to upstream libp2p support for the SCION Internet architecture. As a first step, this PR reserves a code for SCION multiaddrs like /scion/19-ffaa:1:1079....

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.

No objections from my end. Interesting project.

That said, what is the benefit for tracking it here without an implementation? Why not experiment with the Private Use Range first and only reserve the multicodec once there is a first implementation using it?

@rvagg
Copy link
Member

rvagg commented Jun 6, 2023

I'll wait for @leonrinkel's response to the above question, but wrt multiaddr and private range, we've recently had an issue with IPNI using a private range for httpath, in the wild, for some time now (although it seems like we might be heading in a different direction with this #324). Since multiaddrs get encoded in binary form, it does matter that the number is encoded in the table.
So I think it's fine to go ahead with this as long as it seems reasonable that this isn't vapourware and we'll be stuck with an entry that never gets used at all.

@leonrinkel
Copy link
Contributor Author

We do have an implementation that we're experimenting with and I'm trying to upstream it step by step. I just thought it would be the right order to do this first. I'll open a multiaddr PR asap, it's only minor version bumps in the SCION net library that I'm still waiting for. But I see your point, if you want to wait till then and cross-reference, that is also fine for me.

Copy link
Member

@rvagg rvagg left a comment

Choose a reason for hiding this comment

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

since there's not an explicit rejection from the libp2p team I see no reason to hold this up. @leonrinkel if this ends up going nowhere then it'd be great if you could come back and PR for a removal, but it seems to me from what you've said and the existence of code that this has a future in an attempt at least, which is good enough.

@rvagg rvagg merged commit b98f2f3 into multiformats:master Jun 9, 2023
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.

3 participants