[question] can I prevent peer's from connecting?

[florianlenz]

Hi,

I have a few questions. I hope this is the right place to ask them (or should I use stack overflow)?

1. Is there a way to prevent peer's from connecting to me?
2. Can i create a stream that can only be used by peer's that are authorised? If so, where can I find information on how todo it?
3. For what is the consensus lib used?

Thank you.
P.s. It might be nice to have a libp2p gitter channel.

[Stebalien]

I have a few questions. I hope this is the right place to ask them (or should I use stack overflow)?

For now, this is the right place (small enough user-base).

P.s. It might be nice to have a libp2p gitter channel.

You can usually find us on the #libp2p Freenode IRC channel.

---

Is there a way to prevent peer's from connecting to me?

I.e., you want to prevent inbound connections? Yes. You should be able to configure libp2p to not listen on any addresses (although this hasn't been tested extensively so you may run into interesting issues). However, this generally isn't advised.

Are you interested in creating a private (permissioned) network or do you just not want to accept incoming connections. We have a feature called private networking for the former (unfortunately, the documentation is a bit sparse for use outside of go-ipfs).

Can i create a stream that can only be used by peer's that are authorised? If so, where can I find information on how todo it?

So, you can either use private networking as noted above or you can simply check. That is, when your service accepts the stream, it can check the peer ID of the remote peer against a list of allowed peers (peer IDs are authenticated).

For what is the consensus lib used?

Our raft implementation: https://github.com/libp2p/go-libp2p-raft. However, I don't believe we use that for anything at the moment (and I'm not entirely sure how complete the implementation is).

[florianlenz]

I.e., you want to prevent inbound connections? Yes. You should be able to configure libp2p to not listen on any addresses (although this hasn't been tested extensively so you may run into interesting issues). However, this generally isn't advised. Are you interested in creating a private (permissioned) network or do you just not want to accept incoming connections. We have a feature called private networking for the former (unfortunately, the documentation is a bit sparse for use outside of go-ipfs).

My goal is to prevent a set of peer's from connecting to me. So I might want allow peer A to connect to me, but I want to prevent that peer B connect to me.

So, you can either use private networking as noted above or you can simply check. That is, when your service accepts the stream, it can check the peer ID of the remote peer against a list of allowed peers (peer IDs are authenticated).

Where exactly does the "accept" happen? Shouldn't I prevent the stream from beeing opened / accepted? Or does that make no sense? Does the stream need to be opened so that I can retrieve the peer id?

Thank you for your help :)

[hsanjuan]

For what is the consensus lib used?

Our raft implementation: https://github.com/libp2p/go-libp2p-raft. However, I don't believe we use that for anything at the moment (and I'm not entirely sure how complete the implementation is).

ipfs-cluster uses go-libp2p-raft. This is a wrapper of hashicorp/raft which implements the libp2p-consensus interface and includes a libp2p-transport implementation for the original hashicorp/raft library.

Does the stream need to be opened so that I can retrieve the peer id?

yes, as authentication of the stream can only happen after both ends have exchanged information.

[florianlenz]

@Stebalien

So, you can either use private networking as noted above or you can simply check. That is, when your service accepts the stream, it can check the peer ID of the remote peer against a list of allowed peers (peer IDs are authenticated).

Checking the peer id seem's to be the way to go. Is there a way to check the peer id earlier? Maybe by registering a (network listener)[https://github.com/libp2p/go-libp2p-net/blob/master/interface.go#L153]? I would then listen for the Connected event and Immediately drop the connection in case I would like to. The question is, are all listener's called before the connected peer is able to create a new stream with me?

Have a nice weekend :)

[Stebalien]

The question is, are all listener's called before the connected peer is able to create a new stream with me?

Unfortunately not because quit a few services need to connect (via a stream) to all new peers. To correctly support this, we'd need multiple event rounds.