You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: