Question: Extending Gossipsub protocol list

[richard-ramos]

Is it possible to extend the list of protocols returned in:

go-libp2p-pubsub/gossipsub.go

Lines 401 to 403 in 5457a28

	func (gs *GossipSubRouter) Protocols() []protocol.ID {
	return []protocol.ID{GossipSubID_v11, GossipSubID_v10, FloodSubID}
	}

I'd like to include an additional ID besides GossipSubID_v11, GossipSubID_v10, FloodSubID, yet I find it difficult to extend GossipSubRouter to include my custom ID.

Floodsub supports this feature with NewFoodsubWithProtocols

go-libp2p-pubsub/floodsub.go

Lines 17 to 22 in 5457a28

	func NewFloodsubWithProtocols(ctx context.Context, h host.Host, ps []protocol.ID, opts ...Option) (*PubSub, error) {
	rt := &FloodSubRouter{
	protocols: ps,
	}
	return NewPubSub(ctx, h, rt, opts...)
	}

Is adding a similar functionality something viable? I could create a PR that adds a NewGossipsubWithProtocols(ctx context.Context, h host.Host, ps []protocol.ID, opts ...Option) (*PubSub, error)

[vyzo]

In principle we could, but there is some impedance mismatch in that the router uses the protocol ID to enable certain features.
For example, it checks for the floodsub ID to determine whether to just treat those peers as simple floodsub peers.
It also checks for the GSv1.1 ID to check whether to enable PX.

[richard-ramos]

Here's the code for my previous idea:
master...richard-ramos:master

There is some impedance mismatch in that the router uses the protocol ID to enable certain features.

Perhaps this coud be solved by always return GossipSubID_v11, GossipSubID_v10, FloodSubID, yet still allowing to add custom protocols? Something like this code:

func (gs *GossipSubRouter) Protocols() []protocol.ID {
	ps := []protocol.ID{GossipSubID_v11, GossipSubID_v10, FloodSubID}
	return append(ps, gs.protocols...)
}

If having this logic is not desirable, would you mind sharing some tips on how could I achieve something similar with the current implementation of GossipSub?

[vyzo]

Sure, but how should the router behave towards the custom protocol? Is it gsv1.1 compatible? Also, its not entirely clear to me why you want a custom protocol -- what do you gain by it?

…

On Tue, Mar 23, 2021, 20:01 RichΛrd ***@***.***> wrote: Here's the code for my previous idea: master...richard-ramos:master <master...richard-ramos:master> There is some impedance mismatch in that the router uses the protocol ID to enable certain features. Perhaps this coud be solved by always return GossipSubID_v11, GossipSubID_v10, FloodSubID, yet still allowing to add custom protocols? Something like this code: func (gs *GossipSubRouter) Protocols() []protocol.ID { ps := []protocol.ID{GossipSubID_v11, GossipSubID_v10, FloodSubID} return append(ps, gs.protocols...) } If having this logic is not desirable, would you mind sharing some tips on how could I achieve something similar with the current implementation of GossipSub? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#408 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAI4SUCHT22FYBGR5AFE6DTFDJOBANCNFSM4ZVULGEA> .

[richard-ramos]

I'm attempting to implement this spec: https://specs.vac.dev/specs/waku/v2/waku-relay
The TLDR is:

• It's a thin layer over GossipSub
• Has the following protocol identifier: /vac/waku/relay/2.0.0-beta2
• Uses StrictNoSign

I tried to implement it without forking go-libp2p-pubsub, but found it very difficult to do so, hence why attempted to implement it here using the solution that I described earlier: https://github.com/status-im/go-waku/blob/master/waku/v2/protocol/waku_relay.go#L29-L43

[vyzo]

ok, I see. The proper solution would be to support a custom protocol list with a feature check function. I would accept a pr implementing this so that you dont have to maintain a fork.

…

On Tue, Mar 23, 2021, 20:55 RichΛrd ***@***.***> wrote: I'm attempting to implement this spec: https://specs.vac.dev/specs/waku/v2/waku-relay The TLDR is: - It's a thin layer over GossipSub - Has the following protocol identifier: /vac/waku/relay/2.0.0-beta2 - Uses StrictNoSign I tried to implement it without forking go-libp2p-pubsub, but found it very difficult to do so, hence why attempted to implement it here using the solution that I described earlier: https://github.com/status-im/go-waku/blob/master/waku/v2/protocol/waku_relay.go#L29-L43 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#408 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAI4SQ77JV4BSRP4D423TTTFDPZNANCNFSM4ZVULGEA> .

[richard-ramos]

Cool! I will start working on it!
Do you have specific requirements on how should this feature check function work?

Thanks!

[vyzo]

well, we should normalize the features we check by protocol ID, should be straightforward.

…

On Tue, Mar 23, 2021, 21:26 RichΛrd ***@***.***> wrote: Cool! I will start working on it! Do you have specific requirements on how should this feature check function work? Thanks! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#408 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAI4SV3PRK4T2CRWHW7JRTTFDTPLANCNFSM4ZVULGEA> .

[BigLep]

@richard-ramos : are you planning to open a PR here?

[richard-ramos]

Hello @BigLep, I'm not able to work on a PR for this for the time being!

[vyzo]

@richard-ramos

Implemented support for custom gossipsub protocols in #413.

To use it, just instantiate your gossipsub using the WithGossipSubProtocols option; it takes a list of protocols and a feature test function.

So you shouldn't have to maintain a fork anymore and miss out on all the bug fixes and new features.

[richard-ramos]

Awesome! thank you!