Chore/add typedefs peerstore book template 2#831
Conversation
* feat: auto relay * fix: leverage protoBook events to ask relay peers if they support hop * chore: refactor disconnect * chore: do not listen on a relayed conn * chore: tweaks * chore: improve _listenOnAvailableHopRelays logic * chore: default value of 1 to maxListeners on auto-relay
Co-authored-by: Jacob Heun <jacobheun@gmail.com>
BREAKING CHANGE: pubsub signing policy properties were changed according to libp2p-interfaces changes to a single property. The emitSelf option default value was also modified to match the routers value
* feat: custom dialer addr sorter * chore: use libp2p utils sorter via addressBook getMultiaddrsForPeer * chore: use new libp2p utils * chore: apply suggestions from code review Co-authored-by: Jacob Heun <jacobheun@gmail.com> Co-authored-by: Jacob Heun <jacobheun@gmail.com>
* chore: auto relay example * chore: update examples to use process arguments * chore: add test setup for node tests and test for auto-relay * chore: apply suggestions from code review * chore: do not use promise for multiaddrs event on example
* chore: update websockets
Co-authored-by: Irakli Gozalishvili <contact@gozala.io>
|
Added a commit merging in the new updates of the base types branch to check this |
66b9abd to
222bb7b
Compare
671ba33 to
e014fee
Compare
src/upgrader.js
Outdated
| const { stream, protocol } = await mss.handle(Array.from(this.protocols.keys())) | ||
| log('%s: incoming stream opened on %s', direction, protocol) | ||
| if (this.metrics) this.metrics.trackStream({ stream, remotePeer, protocol }) | ||
| // @ts-ignore - metadata seems to be required |
|
This looks good to me! However, a new issue appeared as a result of this update... This only happens with the new ts. If you look into the dist on |
Yes, this sounds good! I will add it to the follow up list to not block this anymore. |
1d3492f to
2e7f49e
Compare
|
Discussion continued in #830 |
This pull request does following:
@vasco-santos one other thing I want to call out here is that this change turns
StreamHandlerinto non generic, that is because it usesCircuitPBencode / decode which in turn expects concrete structs. I am however not exactly sure I got all the details right, specifically:CircuitRelayprotobuf all fields are optional.CircuitRequestwith all fields (butcode) mandatory.StreamHandlerseems to always containcode & typeStreamHandlerare assumed to havetypesrcPeer,dstPeer.Which is what were reflected in the StreamHandler API reads return
CircuitRequests with all the mandatory fields and writes takeCircuitMessages with all the optional fields. However I am guessing thatCircuitMessagein fact is more of a union of different message types where each corresponds toTypeenum and has different subset of fields & probably each must have some subset of the the fields and that is why protobuf just marks them all optional.If above hypothesis is correct it would make much more sense to represent each
messagetype via actual type definition with it's fields and representCircuitMessageas a type union. It would be good to sync up on this to fix those details up.