Trouble attributing validation error

[wemeetagain]

Gossipsubv1.1 has the following spam protection:

In flight IWANT requests, sent as a response to an IHAVE advertisement, are probabilistically tracked. For each IHAVE advertisement which elicits an IWANT request, the router tracks a random message ID within the advertised set. If the message is not received (from any peer) within a period of time, then a behavioural penalty is applied to the advertising peer through P₇. This measure helps protect against spam IHAVE floods by quickly flagging and graylisting peers who advertise bogus message IDs and/or do not follow up to the IWANT requests.

In go-libp2p-pubsub, they can attribute the invalid message to a specific reason. This lets them properly score the peer/message based on the reason: https://github.com/libp2p/go-libp2p-pubsub/blob/master/score.go#L563

Unfortunately, based on the current design of js-libp2p-pubsub, we are not able to determine why a message is invalid. Only that it is (it returns a boolean, valid/invalid). Earlier in the gossipsubv1.1 effort, we extended our extension of validate to include topic validators and a function to process topic validator errors: here, but this is insufficient to track other causes of a message being invalid, eg: invalid or missing message signature.

A fix for this very likely requires modifying js-libp2p-pubsub in some way.

One possibility is to have validate throw an Error using js-errcode.
We could then extend validate to handle errors of different codes, and make our scoring code quite similar to the above go-libp2p-pubsub example.

Here is another relevant section of go-libp2p-pubsub: https://github.com/libp2p/go-libp2p-pubsub/blob/8945f91465bc3ba418688684a2c29c384cd79647/pubsub.go#L924

Open to other ideas of how to proceed.

[wemeetagain]

@vasco-santos

[vasco-santos]

One possibility is to have validate throw an Error using js-errcode.

This approach makes sense and we have it in other subsystems like the DHT. I think that we should proceed that way

[wemeetagain]

resolved in #110