Feed or Inbox Watcher¶

A feed or inbox watcher monitors an external message stream and reacts when it sees a specific item, such as a newly published post or a newly received email.

Contract and service split¶

Contract¶

• defines what should happen when a matching message is found
• stores any durable deduplication or handled-message state
• applies the final accepted effect on-chain

Service¶

• polls the external feed or inbox
• extracts a stable identity for the observed message
• sets event-id so equivalent observations collapse together
• emits the contract call that should happen once validators agree

How it works¶

1. A funded wallet submits requests that ask the service to poll some external source.
2. Validators execute the watcher service locally.
3. The service finds a message of interest and emits a service-response.
4. Instead of using the default request-id, the service sets event-id to the identity of the observed message.
5. Validators aggregate responses by (service, event-id) rather than by (service, request-id).
6. Once quorum agrees on that logical event, the target contract executes.

Concepts introduced¶

event-id¶

By default, responses are grouped per request. A watcher often cares about the identity of the observed message instead.

If request #20 and request #30 both discover the same email or the same feed item, event-id allows those responses to collapse onto one logical observation.

Deduplication across time¶

The important fact is not which request first found the message. The important fact is that validators agree they saw the same message.

External identity¶

The event-id should be derived from something stable, such as a message ID, canonical URL, or content hash, so validators can converge on the same logical key.