[Protocol Upgrade Version 1.2] Resolve breaking merge and fork logic

[FantasticoFox]

Protocol upgrade v1.2

This shell be developed against a new branch: "version_1.2_upgrade":

The current protocol version has an unresolvable issue:

• which is caused by the situtation that witness and signatures were lying next to the revision
• this can lead to the situation that the same exported revision could have a different remote signature or remote witness event to your local revision, when merging this would lead to unresolvable situation

To resolve the issue we MUST store the signature and witness event with the NEXT revision which is produced by a FORCED INJECT anytime a witness or signature is created.
This inject for the witness behaves similarly to the inject of the current existing signature (refering to the witness_event_page).

In this step we would like to change the datastructure of the revision:

type Revision = {
  content: {
    content: {[key: string]: string}
    file?: string, // base64 encoded file
    content_hash: string, //SHA3-512 Hash
  },
  metadata: { 
    "AQUA" (exactly this),
    version (exactly 4 characters / version number / string),
    time ("YYYYMMDDhhmmss" / numbers only / string),
    domain (variable length, maximum of 64 bytes / hex encoded / string),
    metadata_hash: string, //SHA3-512 Hash
  },
  prev?: {
    verification_hash: string, //SHA3-512 Hash, this is moved from metadata out
    signature?: {  //wallet_address removed as it can be derived from pub_key
      signature: string, // 0x prefixed 65 bytes (ethereum standard)
      public_key: string, // 0x prefixed 65 bytes (different ethereum standard)
      signature_hash: string, //SHA3-512 Hash
    }
    witness?: { //only necessary for verifier listed here
      domain_snapshot_genesis_hash: string, //SHA3-512 Hash
      merkle_root: string //SHA3-512 Hash,
      merkle_tree: ProofNode[],
      witness_network: string,
      witness_event_transaction_hash: string, //0x prefixed 32 bytes hex encoded
      witness_hash: string, //SHA3-512 Hash
    }
  },
  merge?: {} //same as prev
};
type ProofNode = {
    left_leaf: string, //SHA3-512 Hash
    right_leaf: string, //SHA3-512 Hash
};

• ? means its optional field with data or null

Hasher-Changes

verification_hash = sha3(
    content.content_hash +
    metadata.metadata_hash +
    prev?.reference_hash + //requires additional hashers
    merge?.reference_hash //requires additional hashers
)
//new hashers
for ref in [ prev, merge ] do {
    ref.reference_hash = sha3(
        ref.verification_hash +
        ref.signature?.signature_hash +
        ref.witness?.witness_hash
    )
}

metadata.metadata_hash = sha3(
    "AQUA"
    protocol_version +  
    metadata.domain_id +
    metadata.timestamp
)

// stays the same for now

content_hash = sha3(
    sort_by_keys(content.content).values
)

We reinterpret the meaning of the signature and witness which is given out with a revision.
They are always referring to the previous_revision.

We remove the fields:

• verification_context

• signature.wallet_address

• Export / Import API entity changes

API adjustments

• get_server_info: iterate to new version
• verify_page: deprecate if not needed, please check
• get_page_all_revs: can be deprecated if not used internally
• get_revision needs to be adjusted for new ExportImportEntity
• get_hash_chain_info/genesis_hash: must be deprecated // should stay for title
• get_revision_hashes is replaced with get_branch inblockio/mediawiki-extensions-Aqua#375
• New: get_latest_hashes inblockio/mediawiki-extensions-Aqua#372
• write/store_signed_tx logic must be adjusted
• write/store_witness_tx inject into revision
• New: delete_revisions endpoint required to work with revision_hash [Feature Request] Expose "Delete Revision by verification_hash" for enabling deletion feature of Guardian mediawiki-extensions-Aqua#366
• import must work with new ExportImportEntity

Further todos:

• adjustment of verifier.js / webverifier / rust-verifier
• testing of import / export with files

[FantasticoFox]

Store revision API does not allow for storing single revisions correctly as SiteInfo and Context are currently required.

An idea which we will explore is, what happens if we add to the content (invisible) what we need to ensure that the MediaWiki context is satisfied by storing:

• genesis_hash (identification of chain)
• title (the title the revision had at that time) (should only change it when content of the page is changed to avoid creating new revisions on move/title change ?)
• namespace_id (the local namespace id)
• namespace_title (the local namespace title)

This will give us all we need to import the revision into the PKC.
Further we ensure that title and genesis hash are both part of the revision and with it part of the verified context.
We keep it in content to ensure that MediaWiki specifics do not alter the protocol structure.

[FantasticoFox]

This has partially completed, must notably the FORCED INJECT anytime a witness or signature is created.

Also moving the storing of the witness and signature TO the newly created revision and using their witness_hash / signature_hash as input for the verification hash of the newly created revision.

Other chances are still open