CIP: 12 Title: Enabling External Automator through Broadcasts Authors: Cryptcoin Junkey Discussions-To: Status: Draft Type: Standards Created: 2018-06-23
Any user should be able to bind an address under their control to their Automator (a.k.a Bot). The protocol should track if an address is watched by Automator.
To lessen end user costs of application development by supporting PubSub relation between addreses (publisher) and Automators (subscriber) at the protocol level.
In some cases, powerful end user may want to run Automator. It may want to watch trigger event, to execute on off-chain, and to send Counterparty messages. Currently, it is required to hack Counterparty-server / Counterblock or to keep polling servers. They will be high-cost for users. At the same time, on nodes side, it will requires huge costs if broadcast all chain events to Automators.
In such case, the one of the best practice is PubSub pattern. Each Automator is bound to each address. And a owner of Automator sets the flag that request sending events on every message related on the address.
The protocol doesn't care about how the event should be published, just registers the flag. It is a node side matter that each nodes how to connect Automators. It will required another CIPs to define connection protocols.
There will be a 'special' broadcast with address options same as CIP12.
OPTIONS <INTEGER>
INTEGER
: a bitwise operation that identifies the desired options
The REQUIRE_PUBLISH flag (bit two) may be turned on or off as many times as desired with successive OPTIONS broadcast messages.
Note that INTEGER
will be over-written. There should be set REQUIRE_MEMO | REQUIRE_PUBLISH
if REQUIRE_MEMO
was set before.
- When validating a send attempt (send.validate):
- Check if destination address requires memo
- Check if transaction has a memo included
- When parsing a broadcast (broadcast.parse)
- Check if source address require publish
- If publish is required, send event to associated Automator(s).
- Check for
OPTIONS <INTEGER>
as the broadcast text - Verify that address is not LOCKed by checking for previous LOCK broadcast
- If INTEGER is greater than than the maximum flag used, then the OPTIONS broadcast will be ignored. As of this CIP, only 2, 1 or 0 are accepted.
- Create/Update record in
addresses
table and set OPTIONS
This is optional, Implementation dependent.
- When parsing a message (*.parse)
- Check if source address require publish
- If publish is required, send event to associated Automator(s).
This document is placed in the public domain.