Jacob Heun

I'll add to this later today and will include links to pertinent conversations.

You could work around this by tracking the bandwidth stats from metrics, https://github.com/libp2p/go-libp2p-core/blob/master/metrics/bandwidth.go, and then performing disconnects of peers who exceed this. I don't believe there is a way to...

> or we can simply pass the config file as argument, better than reading from stdin. I'm good with this approach

The only other two methods I can see being useful to expose would be - `GET_PEER_INFOS`, get PeerInfo's for a list of peer id's and, - `GET_PEERS`, get a list...

> And again, we don't want to expose the `SET_PROTOCOLS` method It's not implemented and I don't intend to add it, are you referring to `ADD_PROTOCOLS`? Is `SUPPORTS_PROTOCOLS` even necessary...

I've added some more types based on the available interfaces. If those look good I will add accompanying specs for those requests. I didn't include the `PeerMetadata` interface for now...

Here's an updated list. I removed metrics as that's probably unnecessary at this point. I think this gives us a good base for interacting with the Peerstore. **Peer operations** `GET_PROTOCOLS`...

I like this approach, I think it would be great to get spec'd out. When implementing the js daemon I referenced the cli parser of the go implementation, but it...

The protocols are discovered and added to the Peer Store during Identify, there's just currently no trivial way for us to get those known protocols from the Daemon. Right now...

Unless I am missing something, the only way to currently use identify directly on a peer would be to implement the identify protocol in a daemon client and perform that...