We would like a way to enable messages to still be sent to the application level, even if the message is invalidated (ValidationIgnore) by a topic validator.
Perhaps we could introduce a new type of Validation Response like ValidationIntercept, which signals that we don't want to forward or gossip the message, but we want to still have the message delivered to us at the application level.
One important thing to note here is that we may actually have to allow the application to modify the message data in order to do the validation. For example, the message payload may be serialized, but we may need to look at the deserialized data in order to do the validation. We wouldn't then want to pass the original message to the application, since then it would need to deserialize a second time.
Today, this can be accomplished by passing the message from the validation function into a side channel, but this is a hack and I would like to design a better way of supporting this use case.
Context: https://discuss.libp2p.io/t/topicvalidator-which-delivers-to-the-application-but-does-not-forward-to-the-network/1010
We would like a way to enable messages to still be sent to the application level, even if the message is invalidated (ValidationIgnore) by a topic validator.
Perhaps we could introduce a new type of Validation Response like ValidationIntercept, which signals that we don't want to forward or gossip the message, but we want to still have the message delivered to us at the application level.
One important thing to note here is that we may actually have to allow the application to modify the message data in order to do the validation. For example, the message payload may be serialized, but we may need to look at the deserialized data in order to do the validation. We wouldn't then want to pass the original message to the application, since then it would need to deserialize a second time.
Today, this can be accomplished by passing the message from the validation function into a side channel, but this is a hack and I would like to design a better way of supporting this use case.