Idiomatic way to create transport without authentication

[oskin1]

Is there a way to do something like this?

  let transport = tcp::async_io::Transport::default()
      .upgrade(Version::V1Lazy)
      .multiplex(yamux::Config::default())
      .boxed();

[thomaseizinger]

There is https://github.com/libp2p/rust-libp2p/tree/master/transports/plaintext. Don't run this in production though.

[oskin1]

Isn't it safe to run it in production if the network is completely open and trustless?

[thomaseizinger]

You seem to have a misguided understand on what trustless means.

In a trustless network, you do not need to trust that the remote is who they claim to be. Instead, strong cryptography is used which proves ownership over a private key and thus ties their identity to a particular public key (which is embedded in the PeerId).

With libp2p-plaintext, the remote can send you any PeerId they want and you'll have to trust them because there is no cryptographic proof attached. (Needless to say that all the traffic is open, meaning any intermediary and read and modify the traffic as they want).

[oskin1]

What you're saying is totally clear, maybe I wasn't specific enough.
Some protocols of my application do use cryptography, but for some of them e.g. noise just creates redundant overhead.
So ideally I'd like to derive PeerId from Multiaddr on the level of transport (bc it's shared across all protocols within a single swarm), I guess this will be equal to security level of Bitcoin's P2P.
Is it a viable approach in the context of libp2p? Maybe you could recommend a better one based on your experience?

[thomaseizinger]

Is it a viable approach in the context of libp2p?

If you know what you are doing, yes. Note that pretty much every protocol we have in this repository operates under the assumption that data on a stream is authenticated so you won't be able to use any of the existing protocols.

Maybe you could recommend a better one based on your experience?

It really depends on what you want to do. Accepting double encryption can be a viable approach depending on the size and amount of your messages. You can also modify your protocol to assume an encrypted and authenticated transport. That would probably be my first attempt.

[oskin1]

@thomaseizinger Thanks for your help, Thomas!