Skip to content

Instantly share code, notes, and snippets.

@cryptcoin-junkey
Created June 23, 2018 06:42
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save cryptcoin-junkey/7c1a53a2e38e95f361936bf358a3cbe9 to your computer and use it in GitHub Desktop.
Save cryptcoin-junkey/7c1a53a2e38e95f361936bf358a3cbe9 to your computer and use it in GitHub Desktop.
  CIP: 12
  Title: Enabling External Automator through Broadcasts
  Authors: Cryptcoin Junkey
  Discussions-To: 
  Status: Draft
  Type: Standards
  Created: 2018-06-23

Abstract

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.

Motivation

To lessen end user costs of application development by supporting PubSub relation between addreses (publisher) and Automators (subscriber) at the protocol level.

Rationale

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.

Specification

There will be a 'special' broadcast with address options same as CIP12.

OPTIONS

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.

Changes

Database

Sends

  1. When validating a send attempt (send.validate):
    • Check if destination address requires memo
    • Check if transaction has a memo included

Broadcasts

  1. 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

Messages execpts Broadcasts

This is optional, Implementation dependent.

  1. When parsing a message (*.parse)
    • Check if source address require publish
    • If publish is required, send event to associated Automator(s).

Copyright

This document is placed in the public domain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment