Hi! Currently I'm looking at README.md and have some notes:

• the npm project name is @multiformats/multiaddr but in README multiaddr is used.
  An example: npm i multiaddr in "Install" section
• Since v10.1.0 the package can only be loaded via import. require('@multiformats/multiaddr') will throw as there is no exports for it.
• Why non-breaking spaces are used in README.md? Four such spaces are used in "Usage" section.

I would like to create a PR to fix the above if you can confirm it.

.getPeerId() returns the peer id from a multiaddr if one is present but it may not be the one we expect.

If the mulitaddr is a relay address but doesn't have the relay client's peer id in the address, the peer id returned is that of the relay.

I believe the intention of .getPeerId is to return the peer id of the remote peer that can be dialled using the peer id, not just any peer id that happens to be in the multiaddr.

We could fix this by treating p2p-circuit as a special case and returning the value part of the p2p-circuit tuple if found, or more generally by only returning a peer id if it's in the final tuple?

Refs: libp2p/js-libp2p#1680

The docs say:

addr.encapsulate(str)
Returns a new multiaddress that encapsulates addr in a new protocol string, str.

addr.encapsulate('/sctp/5678')
// <Multiaddr /ip4/127.0.0.1/udp/1234/sctp/5678>

I am fairly sure this is intended to illustrate RFC6951 encapsulation. However, the RFC clearly states that STCP is "encapsulated into" UDP (passive) or, more plainly, UDP encapsulates STCP. So, in this case the docs can be corrected to something like "Returns a new multiaddress that encapsulates a new protocol in the stack already specified by addr"

However, the semantics of decapsulate are wrong at the API level:

addr.decapsulate(str)
Returns a new multiaddress with the right-most protocol string str removed.

multiaddress('/ip4/127.0.0.1/udp/1234').decapsulate('/udp')
// <Multiaddr /ip4/127.0.0.1>

Let's extend this to a fuller example:

<Multiaddr 043692e377062329a5032212204ca777e3b2d5d6dc5524ddb742b3b3fd3ce19e8ef11e3e6172dcc42f73638859 - /ip4/54.146.227.119/tcp/9001/ipfs/QmTVsocFCSEdPyM8dZ734GRhjvvmYyL9fShyezVkbPj17E>
> m.decapsulate('/ip4')
<Multiaddr  - />
> m.decapsulate('/tcp')
<Multiaddr 043692e377 - /ip4/54.146.227.119>
> m.decapsulate('/ipfs')
<Multiaddr 043692e377062329 - /ip4/54.146.227.119/tcp/9001>

There's two problems with this.

One: the API should specify either the outer layer which to strip (as in https://loicpefferkorn.net/ipdecap/) or the inner layer which to return https://tools.ietf.org/html/rfc3948#section-3.3

Two: there appears to be no way to actually get the innermost protocol using these calls -- please correct me if I'm wrong

Both of these issues can be corrected by returning a tuple of [outer, inner] multiaddresses from the decapsulate call.

The current behavior can also be preserved as a getEncapsulatingProtocol method.

Right now, only the constructor and the static methods are exported. This limits the usage to sth like

let x = Multiaddr('...')

but it does not allow requiring Multiaddr as e.g. function parameters

function foo(ma: Multiaddr): void {
    // do sth. nice
}

Adding this might help

export { Multiaddr }

I was not able to find in the docs and I am not sure if there is something for that:
What I want to achieve is a clean way to test if an string is a multi address.

I am not sure if is-ipfs is helping, but I would like to validate specific multiaddr

Is there anything out there? If something pops up, I will comment a link here so other people can find it.

https://travis-ci.org/jbenet/js-multiaddr

I think a static method that checks whether a string or JavaScript Object nodeAddress is a valid Multiaddr or not would be nice to have.

Example:

const validAddr = '/ip4/0.0.0.0/tcp/0';
const notValidAddr1 = '/ip4/0.0.0.0/tcp';
const notValidAddr2 = '/ip4/0.0.0.0/ipfs/asdf';
const notValidAddr3 = { family: 123 };

console.log(Multiaddr.isValid(validAddr))
// => true

console.log(Multiaddr.isValid(notValidAddr1))
// => false

console.log(Multiaddr.isValid(notValidAddr2))
// => false

console.log(Multiaddr.isValid(notValidAddr3))
// => false

Would love to know what you guys think - can try to add this if it's of interest.

Suppose this is my following multiaddr string:

/ip6/fe80::ba27:ebff:fecd:680b%wlp2s0/tcp/5001/p2p/QmVCTgLguTMHTAHKfxQSmML4nUgm33tMrWYKMGxyXeHsVn

After parsing, the host should be

fe80::ba27:ebff:fecd:680b%wlp2s0

but the interface and the % is omitted.

This means that ipv6 link/local addresses are not parsed correctly.
This also creates issues with libp2p-tcp, when attempting to bootstrap a node with a local "neighbor node" as the interface is omitted when converting the string to a multiaddr object.

I've started working on a fix, and will hopefully have a pull request soon, just thought of creating an issue before in case anyone else runs into this

See:
libp2p/js-libp2p-bootstrap#105

Created this issue to track the implementation of DNS support in JS and throughout js-libp2p and js-ipfs

Given multiformats/multiaddr#22 (comment), we need:

• Add support for the DNS code in js-multiaddr
  • .isName method - check if the multiaddr is a name #39
  • .resolve method - resolve the name, if it is a name Needs more consideration, not necessary right now
  • update js-mafmt to for libp2p-webrtc-star to understand that dns is also valid option multiformats/js-mafmt#12
• libp2p-webrtc-star + DNS
  • Migrate libp2p-webrtc-star signalling to use DNS instead
  • Put a libp2p-webrtc-star signalling behind DNS and a reverse proxy with TLS @lgierth
  • Get @lgierth to get a cert for signal.libp2p.io
  • Ensure that it is all good in apps loaded behind https
• Migrate repo/.config to have:
  • libp2p key to isolate all libp2p config specifically
  • addrs to listen (listen)
  • addrs to announce (broadcast)
  • addrs to not announce (filter)
  • Add these distinctions to the peerInfo object too
• Test that a js-ipfs node can dial do a node behind DNS
  • Deploy a node using the dokku thing
  • Test it out
  • Ensure that Identify sends the right addrs

With v7.x.x the default name of protocol 421 was changed from ipfs to p2p. This has led to the situation where this test will fail:

it('parses a string and turns it back into a string', () => {
  const addr = '/ip4/73.109.217.58/tcp/49311/ipfs/QmWjxEGC7BthJrCf7QTModrcsRweHbupdPTY4oGMVoDZXm'
  const ma = multiaddr(addr)
  expect(ma.toString()).to.equal(addr)
})

It's weird because you could use ipfs swarm connect .../ipfs/... but then see .../p2p/... in the output of ipfs swarm peers.

None of this implementations use regex

• Python standard library parse IPv6 function: https://github.com/python/cpython/blob/f8fb0d8e77a0ed765170595a48ff058711eb7fd8/Lib/ipaddress.py#L1607
• Go standard library parse IPv6 function: https://go.dev/src/net/ip.go

• https://github.com/multiformats/js-multiaddr/pull/55/files#r173337049
• https://github.com/multiformats/js-multiaddr/pull/55/files#r173337452

@vmx @dryajov ^^

@ya7ya the correct solution is by doing an actual check of the components. It just happens that constructor.name can't be trusted thanks to asset tooling like uglify.

Most of ipfs / libp2p stack depends on Multiaddr class which introduces large number of dependencies, it is made worth by the fact that typescript forces all of them to agree on the same exact package to type check.

We should instead introduce Multiaddr interface and type our APIs so they take / produce value compatible with that interface. That way they become implementation agnostic allowing us to swap / upgrade implementation without coordinating these changes across the board.

Multiaddr Implementation in this library will just become a one implementation of that interface.

According to https://multiformats.io/multiaddr/ I should be able to type something like /ip4/127.0.0.1/tcp/90/http/baz.jpg

...but this causes Error: no protocol with name: baz.jpg

See https://runkit.com/embed/q1wgjxqmnn38

Work ongoing here for those who might be interested in following: DefinitelyTyped/DefinitelyTyped#41413
Note that if @jacobheun or any other maintainer is ok with having the types here, I'd be happy to PR directly to this repo instead.

We need to add a way to parse ipfs addrs to this module.

Currently go-multiaddr has support for unix path protocol, while the JS implementation does not have it.

This feature is needed in the context of libp2p/js-libp2p-daemon#9

Ref:
multiformats/go-multiaddr#31

The problem is described here: filecoin-shipyard/browser-retrieval#140

It only started recently when we upgraded to the latest libp2p in our package.json.

This issue isn't a blocker for our project, but I thought I should let the js-multiaddr project know about it.

I'm trying to connect to the Polkadot Substrate network and it looks like the multiaddr library is converting all p2p protocol into ipfs

So while I'm able to ping bootnodes for IPFS network, when I try to ping bootnodes for Substrate, I get errors like
Error: dialed to the wrong peer, Ids do not match
or
Error: No available transports to dial peer

I feel like one of the reason is that when I run the command to ping an address like
/ip4/40.117.153.33/tcp/30363/p2p/QmPiGU1jwL9UDw2FMyMQFr9FdpF9hURKxkfy6PWw6aLsur (one of the substrate bootnodes)
it automatically converts it to an IPFS address
/ip4/40.117.153.33/tcp/30363/ipfs/QmPiGU1jwL9UDw2FMyMQFr9FdpF9hURKxkfy6PWw6aLsur

This seems to be coded in the spec:
https://github.com/multiformats/js-multiaddr/blob/master/test/index.spec.js#L223

This is an extension of the discussions from:
https://discuss.libp2p.io/t/libp2p-on-the-polkadot-network/211/3

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two Factor Authentication for your account, set its level to "Authorization only" in your account settings. semantic-release cannot publish with the default "
Authorization and writes" level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

Good luck with your project ✨

Your semantic-release bot 📦🚀

Add the following to export types properly

"types": "src/index.d.ts"

Describe the bug

When using Vite as bundler, it will fail when it cannot find node-fetch. However, if node-fetch is installed, the bundler will fail too, since Node API are not available in browser.

 WARN  Issues with peer dependencies found

.
└─┬ libp2p
  └─┬ libp2p-interfaces
    └─┬ multiaddr
      └─┬ dns-over-http-resolver
        └─┬ native-fetch
          └── ✕ missing peer node-fetch@"*"

To Reproduce

1. Download this project https://github.com/libp2p/js-libp2p/tree/master/examples/libp2p-in-the-browser
2. Run pnpm install
3. Run pnpm start

Expected behavior
multiaddr should not depend on node-fetch

It's not clear from the first textful of README what js-multiaddr does. It's an implementation of multiaddr, but what does that mean? The README should ideally aim to very quickly answer the question "what are the inputs and outputs of this module", or "what does this module do"?

Analagous to the rust implementation:
https://github.com/multiformats/rust-multiaddr/pull/59/files#diff-d8c31d407e43532e4152070bdaf92d7fff58c81b39b4308cad7c769519d31376
And to the go implementation:
https://github.com/multiformats/go-multiaddr/pull/179/files

The goal is to be able to examine and use multiaddrs with these protocols in browserland, too.
Will be useful to the js/ts implementation of the transport.

For reference:
libp2p/specs#412

Hello - due to recent attepts to integrate 3box, IPFS and IPLD into native-react we fell over an issue with multiaddr, which causes the native socket component to fault.
The issue in question is:

The return value of port here is string, as the input type is a string.

• Can we add a parseInt() for the port here?
• Are there cases where the port does not contain the port number?

Refer:
libp2p/js-libp2p-tcp#108

Thanks!
Chris

See ipfs/community#219.

If I JSON.stringify(multiaddr('/ip4/127.0.0.1')) I get "{\"buffer\":{\"type\":\"Buffer\",\"data\":[4,127,0,0,1]}}" should it be '/ip4/127.0.0.1' instead?

TODO: Moved to API-docs, insert link here.

ipfs/js-ipfs#32

TODO (@jbenet)

• merge PR
• change github repo name
• publish to npm

Summary: The ipv4 regex here is what node-ip uses to verify valid ip address format, this logic is being used to validate ip addresses , and right now an invalid address 555.555.555.55 will be converted to a valid address and return 43.43.43.55.

Proposal: I think ideally it would make sense that the regex within the ip-node package were fixed, however the project seems like it hasn't been touched in the past year. Alternatively I think it might make sense to just wrap the calls here and here with a regex check and throw an error just like the package would in the event of an ascii character in the ip address.

Currently, we have to add a protocol to protocol.js file so that it can be valid multiaddr and constructed by the module. This is ok for all of the transports that are standard (TCP, HTTP, QUIC, etc), but for new protocols that are beta, or simply used in the domain of libp2p or another, we don't have a way to extend multiaddr.

We could have a primitive for 'add new protocol', the tricky part is that multiaddr is used in several points and comparing to go-multiaddr, js-multiaddr gets scoped per module. A typical solution for this would be to Inject the multiaddr dependency, however, that would be very cumbersome to have to DI the DI each time a different part in the code adds another multiaddr.

Several options to solve this have crossed my mind, but I couldn't really figure out a clean and elegant way that would work in the browser and in Node.js.

The intermediate solution is to update this module with any protocol that we need to use in our application.

@jacobheun Are there any plans to support conversion to a node address from a dns addr? If so, I can take a stab at it and open a PR. If not, why? Should it be done in some other package?

I also wonder since we would need to check the DNS records if it would need to be async or not. Surely we could keep the API sync.

The code was changed in multiformats/multicodec#16 but that change was never reflected in https://github.com/multiformats/multiaddr.

Am running ipfs-js and get this error:

[ERR_MODULE_NOT_FOUND]: Cannot find package 'dns' imported from
/Users/javaspeak/workspace3/symbiont/permanent_node/server/node_modules/@multiformats/multiaddr/dist/src/resolvers/dns.js

See:

ipfs/js-ipfs#4161

Not sure what the issue is about.

Any guidance much appreciated.

Thank you

When I try to call multiaddress() on a onion address like /onion/3g2upl4pq6kufc4m I get an error in codec.bufferToTuples:
Error: Error parsing address: Invalid address buffer: bc03

Any idea how to solve this? Are onion addresses already implemented?

Describe the bug
Multiple issues across the JS ecosystem when new protocols are added.

To Reproduce
Steps to reproduce the behavior:

1. pull down repo ipfs/ipfs-webui
2. git checkout ea89e7f
3. rm patches/multiaddr+8.1.2.patch
4. npm install
5. start ipfs daemon using kubo 0.18.1 or later in another terminal
   • Note the port number in the line API server listening on /ip4/127.0.0.1/tcp/<kuboPort>
6. run KUBO_PORT_2033_TEST=<kuboPort> npm run test:unit -- src/bundles/identity.test.js
7. Note the error "no protocol with name: quic-v1"

Expected behavior
Looking up unknown protocols does not propagate errors, nor cause requests to fail. We should fallback to supported/known protocols

Additional context

• ipfs/ipfs-webui#2073
• ipfs/ipfs-webui#2033
• ipfs/ipfs-webui#2096

Potential Solutions

1. Pull out protocols-table.js into it's own package. Keep it at v1.0.x, there are NO breaking changes, only protocols added. Any JS package stays up to date by depending directly on the table
2. Stop throwing errors from

   js-multiaddr/src/protocols-table.ts

   Lines 79 to 95 in 6cfb7ad

   	export function getProtocol (proto: number | string): Protocol {
   	if (typeof proto === 'number') {
   	if (codes[proto] != null) {
   	return codes[proto]
   	}
   	throw new Error(`no protocol with code: ${proto}`)
   	} else if (typeof proto === 'string') {
   	if (names[proto] != null) {
   	return names[proto]
   	}
   	throw new Error(`no protocol with name: ${proto}`)
   	}
   	throw new Error(`invalid protocol id type: ${typeof proto}`)
   	}

   , because different packages in the ecosystem are not handling this properly.
3. backport any protocol-table changes for all multiaddr versions (No one wants to do this)

takes like 3 seconds :D

See libp2p/js-libp2p-websocket-star#1
The definition is the same as for libp2p-webrtc-star only the prefix needs to be changed

Canonical CSV states "p2p preferred over ipfs" -

https://github.com/multiformats/multiaddr/blob/master/protocols.csv#L15

JS implementation is currently missing this new name/"alias" -

https://github.com/multiformats/js-multiaddr/blob/master/src/protocols-table.js#L39

Not a huge issue since specifying the /ip4/127.0.0.1/tcp/30333/ipfs/QmWLtV5gpCzJCh9Eo7SxkrT3ZTApovHM1WpCY2Lp3XkaqF does work, however a bit of an annoyance when one implementation (Rust) reports the protocol with /p2p/ and there is some editing before it can be used in a JS client connecting to it.

However, it works, so not a massive issue apart from being a (small) annoyance.

Describe the bug
In https://github.com/multiformats/js-multiaddr/blob/master/src/convert.ts I see:

import { getProtocol } from './protocols-table.js'

Stepping out to the directory view, there is no protocols-table.js. There is, however, protocols-table.ts.

Getting this error when logging a Multiaddr

(node:20190) [DEP0079] DeprecationWarning: Custom inspection function on Objects
via .inspect() is deprecated

Related to this deprecation notice.

Hi there,

Please can you tell me why several of the protocols from protocols.csv are missing from the protocols-table.js.

I was sitting down to write a scala version multiaddr. The js version of multiaddr seems to be the canonical version from which I should copy. Just want to check I am not missing anything.

Thanks!