floodsub example: cannot dial with peer id specified

[ghost]

I'm playing with the floodsub example. Separately, I have a go-libp2p node listening on 127.0.0.1:9876, which subscribes to the same pubsub topic string as the floodsub example.

When I dial without specifying the peer ID (/ip4/127.0.0.1/tcp/9876), it works:

$ RUST_BACKTRACE=1 cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.20s
     Running `target/debug/floodsub-example`
Now listening on "/ip4/0.0.0.0/tcp/10050"
/dial /ip4/127.0.0.1/tcp/9876
*Dialing /ip4/127.0.0.1/tcp/9876*
Successfully negotiated protocol
Successfully negotiated protocol
^C

And the go-libp2p program listening on 9876 sees the inbound connection - yay!

But when I dial with the full multiaddr of the peer on 9876 (/ip4/127.0.0.1/tcp/9876/ipfs/QmehVYruznbyDZuHBV4vEHESpDevMoAovET6aJ9oRuEzWa), it fails like this:

mike@mikevm:~/libp2p-demo-go-js-rust/pubsub/rust/floodsub-example$ RUST_BACKTRACE=1 cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.19s
     Running `target/debug/floodsub-example`
Now listening on "/ip4/0.0.0.0/tcp/10050"
/dial /ip4/127.0.0.1/tcp/9876/ipfs/QmehVYruznbyDZuHBV4vEHESpDevMoAovET6aJ9oRuEzWa
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: UnknownProtocolString', libcore/result.rs:945:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:511
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:426
   6: rust_begin_unwind
             at libstd/panicking.rs:337
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:92
   8: core::result::unwrap_failed
             at /checkout/src/libcore/macros.rs:26
   9: <core::result::Result<T, E>>::unwrap
             at /checkout/src/libcore/result.rs:782
  10: floodsub_example::main::{{closure}}
             at src/main.rs:135
  11: <futures::stream::for_each::ForEach<S, F, U> as futures::future::Future>::poll
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.24/src/stream/for_each.rs:46
  12: <futures::future::map_err::MapErr<A, F> as futures::future::Future>::poll
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.24/src/future/map_err.rs:30
  13: <futures::future::select::Select<A, B> as futures::future::Future>::poll
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.24/src/future/select.rs:52
  14: <futures::future::map::Map<A, F> as futures::future::Future>::poll
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.24/src/future/map.rs:30
  15: <futures::future::map_err::MapErr<A, F> as futures::future::Future>::poll
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.24/src/future/map_err.rs:30
  16: <futures::task_impl::Spawn<T>>::poll_future_notify::{{closure}}
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.24/src/task_impl/mod.rs:314
  17: <futures::task_impl::Spawn<T>>::enter::{{closure}}
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.24/src/task_impl/mod.rs:388
  18: futures::task_impl::std::set
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.24/src/task_impl/std/mod.rs:78
  19: <futures::task_impl::Spawn<T>>::enter
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.24/src/task_impl/mod.rs:388
  20: <futures::task_impl::Spawn<T>>::poll_future_notify
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-0.1.24/src/task_impl/mod.rs:314
  21: <tokio_current_thread::Entered<'a, P>>::block_on::{{closure}}
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-current-thread-0.1.1/src/lib.rs:466
  22: <tokio_current_thread::Borrow<'a, U>>::enter::{{closure}}::{{closure}}
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-current-thread-0.1.1/src/lib.rs:747
  23: tokio_current_thread::CurrentRunner::set_spawn
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-current-thread-0.1.1/src/lib.rs:783
  24: <tokio_current_thread::Borrow<'a, U>>::enter::{{closure}}
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-current-thread-0.1.1/src/lib.rs:746
  25: <std::thread::local::LocalKey<T>>::try_with
             at /checkout/src/libstd/thread/local.rs:294
  26: <std::thread::local::LocalKey<T>>::with
             at /checkout/src/libstd/thread/local.rs:248
  27: <tokio_current_thread::Borrow<'a, U>>::enter
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-current-thread-0.1.1/src/lib.rs:745
  28: <tokio_current_thread::Entered<'a, P>>::block_on
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-current-thread-0.1.1/src/lib.rs:465
  29: <tokio_current_thread::CurrentThread<P>>::block_on
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-current-thread-0.1.1/src/lib.rs:321
  30: tokio_current_thread::block_on_all
             at /home/mike/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-current-thread-0.1.1/src/lib.rs:219
  31: floodsub_example::main
             at src/main.rs:159
  32: std::rt::lang_start::{{closure}}
             at /checkout/src/libstd/rt.rs:74
  33: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  34: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:105
  35: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  36: std::rt::lang_start
             at /checkout/src/libstd/rt.rs:74
  37: main
  38: __libc_start_main
  39: _start

It's obviously choking on the "/ipfs/" part, but I can't figure out why. Specifying a peer id is a valid multiaddr. Maybe this is just not supported yet by rust-libp2p?

My Cargo.toml and full source used here are on a sub-directory in a WIP branch here: https://github.com/mgoelzer/libp2p-demo-go-js-rust/tree/rust-mvp/pubsub/rust

[ghost]

@tomaka : I just discussed this a little with @Stebalien. His view is that in the future we want to only support .../p2p/<peer id> multiaddrs. (For backwards compat reasons, go-libp2p will probably have to keep supporting .../ipfs/<peer id> forever, but not sure that rust-libp2p would want to do this.)

Either way, though, we think it's a bug not to support multiaddrs longer than /ip4/127.0.0.1/tcp/9876 because specifying a peer id (ie, hash of a public key unique to the peer) is a security measure.

Thoughts?

[tomaka]

This is more of a limitation of the floodsub example. We went with the approach of making the user decide whether they would want to do that kind of thing.
It's true however that right now there's so easy way to do this.

In substrate we indeed check the peer ID, however we don't put it as part of the multiaddress.
We have functions that accept both a multiaddress parameter and the expected peer id, instead of passing both as one multiaddress parameter.

[romanb]

Apart from specific of the floodsub example, which no longer exists (I guess it is now the chat example?), the ability to dial /p2p addresses is a necessary part of #1931 and I think this can be considered a duplicate of #1462.