Allow filtering incoming messages by application. #4989
Conversation
CLI.md
Outdated
| * `--accept-messages-with-application-ids <ACCEPT_MESSAGES_WITH_APPLICATION_IDS>` — A set of application IDs. If specified, only bundles with at least one message from one of these applications will be accepted | ||
| * `--reject-messages-with-other-application-ids <REJECT_MESSAGES_WITH_OTHER_APPLICATION_IDS>` — A set of application IDs. If specified, only bundles where all messages are from one of these applications will be accepted |
There was a problem hiding this comment.
and if the same application ID is in both sets? Then the REJECT_MESSAGES_WITH_OTHER_APPLICATION_IDS takes precedence?
There was a problem hiding this comment.
Yes, exactly: both filters are applied, and the stricter one wins.
linera-core/src/client/mod.rs
Outdated
| /// A collection of applications: If `Some`, only bundles with at least one message by any | ||
| /// of these applications will be accepted. | ||
| accept_messages_with_application_ids: Option<HashSet<GenericApplicationId>>, | ||
| reject_messages_with_other_application_ids: Option<HashSet<GenericApplicationId>>, |
There was a problem hiding this comment.
This should probably be documented as well, even if just for completeness.
There was a problem hiding this comment.
How about renaming accept_messages_with_application_ids into reject_message_bundles_without_application_ids ?
There was a problem hiding this comment.
in other places we used required application IDs.
There was a problem hiding this comment.
What names would you suggest for the two fields then?
There was a problem hiding this comment.
I guess we could use restrict_to_application_ids and required_application_ids?
There was a problem hiding this comment.
Funny thing is we already use exactly required_application_ids in ApplicationDescription:
/// Required dependencies.
pub required_application_ids: Vec<ApplicationId>,There was a problem hiding this comment.
And we already use restrict_chain_ids_to.
There was a problem hiding this comment.
@ma2bd: How do you feel about restrict_to_application_ids and required_application_ids?
(These are client options, so it's only clear from the help text, not from the name, that these refer to incoming message bundles. Alternatively, we could also rename restrict_chain_ids_to, to include "messages" or "message bundles".)
CLI.md
Outdated
|
|
||
| * `--restrict-chain-ids-to <RESTRICT_CHAIN_IDS_TO>` — A set of chains to restrict incoming messages from. By default, messages from all chains are accepted. To reject messages from all chains, specify an empty string | ||
| * `--reject-message-bundles-without-application-ids <REJECT_MESSAGE_BUNDLES_WITHOUT_APPLICATION_IDS>` — A set of application IDs. If specified, only bundles with at least one message from one of these applications will be accepted | ||
| * `--reject-messages-with-other-application-ids <REJECT_MESSAGES_WITH_OTHER_APPLICATION_IDS>` — A set of application IDs. If specified, only bundles where all messages are from one of these applications will be accepted |
There was a problem hiding this comment.
sorry but should it be also "message-bundles" here then?
4 participants
Motivation
It's useful to filter out spam messages on a node service that e.g. is running a chain specifically for one application.
Proposal
Allow filtering in two ways:
The latter is stricter, but the former can be useful e.g. for apps that create other apps and then call them.
Test Plan
A test for the new filtering options was added. (Claude)
Release Plan
testnet_conway, thenLinks