# Multiaddr Format Change: /ipfs -\> /p2p

**URL:** <https://discuss.ipfs.tech/t/multiaddr-format-change-ipfs-p2p/6576>\
**Category:** News\
**Tags:** libp2p\
**Created:** [November 1, 2019, 9:12pm UTC](https://discuss.ipfs.tech/t/multiaddr-format-change-ipfs-p2p/6576 "2019-11-01T21:12:00Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![stebalien](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/stebalien/32/156_2.png) [@stebalien](https://discuss.ipfs.tech/u/stebalien)\
**Post date:** [November 1, 2019, 9:12pm UTC](https://discuss.ipfs.tech/t/multiaddr-format-change-ipfs-p2p/6576/1 "2019-11-01T21:12:00Z")

</div>

[[copied from the libp2p forums]](https://discuss.libp2p.io/t/multiaddr-format-change-ipfs-p2p/330)

Libp2p is replacing all multiaddrs of the form `/ipfs/QmFoo` (old-style) with `/p2p/QmFoo` (new-style). The `/ipfs` prefix his an historical artifact from the days before libp2p was split out of IPFS.

All libp2p implementations have supported _parsing_ new-style multiaddrs for at least 5 months (see the [timeline](#timeline)). We are now entering the second phase of this transition and will:

1. Deprecate the old-style (without removing support).
2. Start formatting addresses using the new-style by default.

# Impact

- This change does not affect the network or binary representation of multiaddrs, just the textual representation.
- This change will not affect network interoperability.
- Old nodes (see below) will not be able to parse textual new-style multiaddrs. Specifically, `ipfs swarm connect /p2p/QmFoobar` will not work on go-ipfs releases before 0.4.16 or js-ipfs releases before 0.34.

# Timeline

## Phase 1: Parsing Support

- ✅ go-libp2p - June 26, 2018 (tag gx/v6.0.5)
- ✅ go-ipfs - July 13, 2018 (0.4.16)
- ✅ rust-libp2p - Since the beginning.
- ✅ js-libp2p - April 12, 2019 (0.25.0)
- ✅ js-ipfs - May 22, 2019 (0.36.0)

## Phase 2: Default

- ❌ go-libp2p
- ❌ go-ipfs
- ✅ rust-libp2p - always
- ❌ js-libp2p
- ❌ js-ipfs

---

<div class="post-metadata">

**Author:** ![0zAND1z](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/0zand1z/32/6463_2.png) [@0zAND1z](https://discuss.ipfs.tech/u/0zAND1z)\
**Post date:** [November 4, 2019, 6:14am UTC](https://discuss.ipfs.tech/t/multiaddr-format-change-ipfs-p2p/6576/2 "2019-11-04T06:14:36Z")

</div>

@stebalien, just to be clear, this means that all IPFS production environments planning to add more nodes in the future(running latest versions of go-ipfs/js-ipfs) need to upgrade the go-ipfs/js-ipfs accordingly to address new nodes. Could you please confirm that?

Also, Is there a way to do this up-gradation with a zero downtime? Please advise.

Thanks

---

<div class="post-metadata">

**Author:** ![stebalien](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/stebalien/32/156_2.png) [@stebalien](https://discuss.ipfs.tech/u/stebalien)\
**Post date:** [November 4, 2019, 11:42am UTC](https://discuss.ipfs.tech/t/multiaddr-format-change-ipfs-p2p/6576/3 "2019-11-04T11:42:06Z")

</div>

No. This _will not_ affect network communication or interoperability. It only affects the human readable (textual) multiaddr format.

Basically, ipfs _commands_ will start returning addresses in the format `/p2p/QmFoobar` instead of `/ipfs/QmFoobar`. If you then try to use these addresses with, e.g., an `ipfs swarm connect ...` command on an _old_ ipfs node (e.g., go-ipfs \< 0.4.16), the command will fail.

---

<div class="post-metadata">

**Author:** ![0zAND1z](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/0zand1z/32/6463_2.png) [@0zAND1z](https://discuss.ipfs.tech/u/0zAND1z)\
**Post date:** [November 4, 2019, 12:37pm UTC](https://discuss.ipfs.tech/t/multiaddr-format-change-ipfs-p2p/6576/4 "2019-11-04T12:37:03Z")

</div>

In summary, is the following true?

An IPFS node running on go-ipfs \< 0.4.16 can indeed connect to another IPFS node running on go-ipfs \> 0.4.16. It’s just that during the execution of the swarm connect command on the former node, you need to replace the /p2p/ with /ipfs/ manually, before passing it on.

Is my understanding correct?

---

<div class="post-metadata">

**Author:** ![stebalien](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/stebalien/32/156_2.png) [@stebalien](https://discuss.ipfs.tech/u/stebalien)\
**Post date:** [November 4, 2019, 1:28pm UTC](https://discuss.ipfs.tech/t/multiaddr-format-change-ipfs-p2p/6576/5 "2019-11-04T13:28:01Z")

</div>

Yes.

Note: Interoperability with go-ipfs nodes \<= 0.4.20 will likely break in the near future due to [libp2p/go-libp2p#644](https://github.com/libp2p/go-libp2p/issues/644) anyways. See the [0.4.21 release notes](https://blog.ipfs.io/93-go-ipfs-0.4.21) for details.

---

<div class="post-metadata">

**Author:** ![talb](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/talb/32/3022_2.png) [@talb](https://discuss.ipfs.tech/u/talb)\
**Post date:** [November 4, 2019, 1:31pm UTC](https://discuss.ipfs.tech/t/multiaddr-format-change-ipfs-p2p/6576/6 "2019-11-04T13:31:00Z")

</div>

What about the `/ipns` prefix? Will it change as well?

---

<div class="post-metadata">

**Author:** ![stebalien](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/stebalien/32/156_2.png) [@stebalien](https://discuss.ipfs.tech/u/stebalien)\
**Post date:** [November 4, 2019, 4:05pm UTC](https://discuss.ipfs.tech/t/multiaddr-format-change-ipfs-p2p/6576/7 "2019-11-04T16:05:36Z")

</div>

@talb no. And `/ipfs/QmFile` isn’t changing either. This is specifically about _multiaddrs_.

Old:

- `/ipfs/Qm...`: Either an IPFS file path _or_ a libp2p multiaddr (machine address).
- `/ipns/Qm...`: An IPNS file path.

New:

- `/ipfs/Qm...`: An IPFS file path.
  - `ipfs cat /ipfs/Qm...`

- `/p2p/Qm...`: A multiaddr.
  - `ipfs swarm connect /p2p/Qm...`

- `/ipns/Qm...`: An IPNS file path.
  - `ipfs cat /ipns/Qm...`

Note 1: Commands like `ipfs swarm connect` will continue to _accept_ addresses of the form `/ipfs/Qm...` but this form has been deprecated.

Note 2: This confusion is the primary motivation for making this change.