Allow users to react to certain events

[igamigo]

As a user, you might be interested in note flows and lifecycles specific to your application only. In this sense, the client does not currently provide many mechanisms to programmatically react to events in a specific manner. In other words, in order to update the local view of the blockchain, the user needs to periodically call the Client::sync_state() API which updates the local entities based on the information that it requests and receives. These information is, in turn, based on the previous state (for example, nullifiers are requested for any note that the store is tracking as Committed) and tags (which can be added and removed by the user).

It would be useful for the user to have a way to react to certain events. In general, any received updates might be of interest to the user depending on the application, but some that come to mind as important are:

• Notes matched by tags: It might be of interest to the user to update some other part of the application state based on received notes, or decide which received notes are stored, since tags only partially provide this functionality. This is somewhat related to the NoteScreener which already does this filtering, so perhaps it could be solved by adding a way to programmatically add checks here.
• Notes being consumed (matched nullifiers).
• Transactions getting committed/canceled: This might not be as important, since reacting to updates is currently virtually similar to just manually searching for transactions after syncing. Perhaps this can be solved with just changing the APIs accordingly (for instance, just returning a list of rejected and accepted transactions after a sync).

The mechanisms through which the user could react to these events (event queues that can be consumed, trait objects, callbacks, channels, etc.) can be discussed separately.

[bobbinth]

Notes matched by tags: It might be of interest to the user to update some other part of the application state based on received notes, or decide which received notes are stored, since tags only partially provide this functionality. This is somewhat related to the NoteScreener which already does this filtering, so perhaps it could be solved by adding a way to programmatically add checks here.

I'm wondering if the current NoteScreener can somehow be "morphed" into this customizable functionality. For example, conceptually we could have some on_note_detected() method that could take a note as an input and return NoteConsumability.

Or we could take it even further on_note_detected() look something like this:

pub fn on_note_detected(&self, note: CommittedNote) -> Result<Option<NoteWithProof>, SomeError> {
    ...
}

The default implementation of this method would do all the work of transforming a CommitedNote into some struct (NoteWithProof) which will then be upserted into the store. But the user will be able to override this functionality with a custom implementation.

Not sure if the above makes sense yet - just brainstorming the ideas.