Draft Proposal for ECAF's Official Notification System

in eos •  6 months ago

REQUEST FOR COMMUNITY and BLOCK PRODUCER COMMENTS

The EOS Core Arbitration Forum (ECAF) is aware of the strong need for a consistent, widely-available, verifiable process for posting important messages and official notices. Community feedback is requested on the following draft proposal. Please respond directly and at length in the comments section below.

Nature of Communications

The Arbitration process requires ECAF to communicate several notices to the Community:

  1. Informing Claimants and Respondents of the existence of Arbitration Cases that have been filed naming them as a Party to the case (i.e. a “Notice of Arbitration”) (ECAF Rules of Dispute Resolution, 3.4) Make the Community aware of Arbitrator rulings and orders (RDR 3.5, 6)
  2. Pass rulings and orders to Block Producers for execution (RDR 3.5, 6)

Goals

The following processes have been designed with several considerations in mind:

  1. There is currently no on-chain messaging and notification service that can (verifiably or otherwise) deliver a message to a user or a Block Producer
  2. The process must provide a clear, consistent, permanent record of communications from the ECAF outwards
  3. The process must be highly resistant to spoofing (i.e. another person purporting to be ECAF issuing a notice) and tampering (i.e. another person modifying already issued notices)
  4. The process needs to be broadly in line with the EU GDPR in allowing persons their right to privacy

Official Sources of Communication

These are proposed as 3 definitive sources of information around ECAF notices. When reviewing a notice corroboration of its authenticity MUST be received from at least two of these sources.

These processes may be modified as and when proven methods for on chain communication become available. Any variance in the processes will be announced on BOTH the ECAF website and on its Steemit blog (addresses above), with generous advance notice so that all Block Producers will be informed and have adequate time to act if necessary.

Communication of Notices of Claim / Arbitration

Notices of Claim / Arbitration informational postings which tell parties and the general public that a Claim has been made, or a Case opened and actual arbitration has begun. These notices never contain instructions, directives, opinions, etc.

  • Notices of Arbitration are stored as permalinked TXT files on the ECAF website along with their SHA-3-256 hash. The TXT files are also published simultaneously on SteemIt, along with the same SHA hash
  • Notices of Arbitration are broadcast as follows:
    • Preferably, emails (when available) are sent to Parties to a claim
    • Additionally (or alternatively, when email communication to all parties to a claim cannot be established,) the following public methods are used
      • A post on Steemit from the ECAF account above that includes:
        • A link to the file containing the Notice of Arbitration on the ECAF website
        • The file’s hash
      • A transaction on the EOS MainNet from the EOS account above that includes:
        • A link to the file containing the Notice of Arbitration on the ECAF website
        • The file’s hash

Note that our preference is to rely more and more on the on-chain method above, as and when it becomes available and reliable.

Communication of Orders and Rulings

Orders and Rulings contain instructions, directives, opinions, etc. on which Block Producers will typically act. (For example: blocking or unblocking named EOS accounts. Banning another BP from production.) While all official ECAF communications need to be trusted and verifiable, Decisions / Directives are particularly sensitive as they bear directly on BPs’ executive power.

  • Orders/Rulings are stored as permalinked PDF files on the ECAF website along with their SHA-3-256 hash
  • Orders/Rulings are published as follows:
    • A post on Steemit from the ECAF account above that includes:
      • A link to the file containing the ruling on the ECAF website
      • The file’s hash
    • A transaction on the EOS MainNet from the EOS account above that includes:
      • A link to the file containing the ruling on the ECAF website
      • The file’s hash
  • Once a ruling or order has been published, recipients are notified as follows:
    • To Claimants and Respondents: via any email address that they registered with the forum at the time of filing a claim or when they responded to a Notice of Arbitration
    • To BPs: A message informing BPs of the existence of the ruling/order is issued on the Keybase channel top_eos_bps #orders. It is up to the BPs to ensure that they regularly monitor this channel for Arbitrator orders. The message will include:
      • The file containing the ruling and its hash
      • For verification:
        • A reference to the on chain EOS transaction from the ECAF’s EOS account that contains both file’s link and its hash
        • A link to the Steemit post referencing both the file’s link and its hash
        • Optionally, for cases of particular significance or Community interest, the ECAF may elect to do a recorded video call to attest to the veracity of the order. This call will involve the Arbitrator assigned to the case, a Case Manager and several known BPs. Such recording will also be published on the ECAF website
    • To the Community: via the ECAF website with verification from either the Steemit blog or on-chain message
Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

@ecaf, I gave you an upvote on your post! Please give me a follow and I will give you a follow in return and possible future votes!

Thank you in advance!

Thanks for your immediately response. There is one question I need to ask, In the GOAL part, why we should let the process be in line with the EU GDPR ? Because EU GDPR is an off-chain legislation which only be effective for EU residents.

·

Good question. I imagine the thinking is, to prevent avoidable future problems. If the system can be designed to comply with GDPR, why not do so?

As opposed to deliberately ignoring the existence of GDPR and opening the door to whatever irritating enforcement actions may arise as a result. (I am presuming that ECAF can perform its functions while complying. If there were a trade-off between ECAF doing its job vs complying with GDPR, I'd probably take a different stance.)

In sum, why invite avoidable drama?

it's a great idea to create a protocol which can be guiding line in communication between BP and Arbitrator.