Plutus data encoding differs to other Cardano tools

[catch-21]

Looking at block transactions I can see data associated with Plutus scripts but the encoded values are not what I'm used to seeing with tools such as the plutus serialiser and cardano-cli (of course it is essential that these two are compatible). Script and data hashes are all base16, which is same as cardano-cli.

For example (see testnet transaction json below), the datum associated with hash 9ad30ffde0d1931ed4f145fa0a0d320a067051bfab1b08cbdb79e9f26df55df3 is TEhlbGxvIFdvcmxkIQ==. I've only used hex format for this, like 48656c6c6f20576f726c6421.
Similarly, the plutus script below is WFsBAAAzMiIyMjIzIjIyIiUzUwCzM1AKAJADUAQQBxNQBQBxN1KRAQxIZWxsbyBXb3JsZCEAEjUAQ1MAIAFJhIAEgARJiIzNXNGbrwAgAQBgBRIAESIAISIAEgAR, plutus serialises script bytecode as cbor hex for cardano-cli to use like 585d585b010000333222323232332232322225335300b333500a009003500410071350050071375291010c48656c6c6f20576f726c642100123500435300200149848004800449888ccd5cd19baf0020010060051200112200212200120011.

Additionally, Cardanoscan use familiar encoding format. See https://testnet.cardanoscan.io/transaction/39289acb6e80a1553a989a1ba310496d350844fe0dc45ce877044f2575e8b961?tab=contracts

There's certainly a benefit to having consistent encoding formats, at least from a human's perspective. What is the encoding format you've chosen to use here, and how is it better suited than cbor hex?

{
  "witness": {
    "signatures": {
      "2b316f0f6a3a3d4b82756b5a24791aa25ff4bb5102e3504d7a96203e542f8e2b": "hkK91gYqJ2V9U1KDW9L1goGbTF/4qyrTWNYWmmFRmOijvI674dIqdw1hyC84zf3HANaIrBHywSN6aSddoxwHCg=="
    },
    "scripts": {
      "ed9668ffa930f8ae2ac143281d664f220ff329babd3c3740980fbf51": {
        "plutus": "WFsBAAAzMiIyMjIzIjIyIiUzUwCzM1AKAJADUAQQBxNQBQBxN1KRAQxIZWxsbyBXb3JsZCEAEjUAQ1MAIAFJhIAEgARJiIzNXNGbrwAgAQBgBRIAESIAISIAEgAR"
      }
    },
    "datums": {
      "9ad30ffde0d1931ed4f145fa0a0d320a067051bfab1b08cbdb79e9f26df55df3": "TEhlbGxvIFdvcmxkIQ=="
    },
    "redeemers": {
      "spend:0": {
        "redeemer": "2HmA",
        "executionUnits": {
          "memory": 8034,
          "steps": 2712168
        }
      },
      "spend:1": {
        "redeemer": "2HmA",
        "executionUnits": {
          "memory": 8034,
          "steps": 2712168
        }
      }
    },
    "bootstrap": []
  },
  "id": "39289acb6e80a1553a989a1ba310496d350844fe0dc45ce877044f2575e8b961",
  "body": {
    "inputs": [
      {
        "txId": "49e462b220ddfe932447c32fd75f47d57b5e4392e37d13b3b8e2b3fe030b4ac5",
        "index": 1
      },
      {
        "txId": "49e462b220ddfe932447c32fd75f47d57b5e4392e37d13b3b8e2b3fe030b4ac5",
        "index": 2
      }
    ],
    "collaterals": [
      {
        "txId": "5ee888986d17b4fcf6662d75c76b8bf80fd0ec7e71e537f54aa4476e48060542",
        "index": 1
      }
    ],
    "outputs": [
      {
        "address": "addr_test1vr8nl4u0u6fmtfnawx2rxfz95dy7m46t6dhzdftp2uha87syeufdg",
        "value": {
          "coins": 1821916,
          "assets": {}
        },
        "datum": null
      },
      {
        "address": "addr_test1vr8nl4u0u6fmtfnawx2rxfz95dy7m46t6dhzdftp2uha87syeufdg",
        "value": {
          "coins": 8000000,
          "assets": {}
        },
        "datum": null
      }
    ],
    "certificates": [],
    "withdrawals": {},
    "fee": 178084,
    "validityInterval": {
      "invalidBefore": null,
      "invalidHereafter": null
    },
    "update": null,
    "mint": {
      "coins": 0,
      "assets": {}
    },
    "network": null,
    "scriptIntegrityHash": "57af6e9dde2a50b597b9a437caca199dd5f4caa2f512c24cb717207a0abcd04b",
    "requiredExtraSignatures": []
  },
  "metadata": null
}

[KtorZ]

Yes indeed, Ogmios has made some opinionated choices for various encoding. The rule of thumb is that:

• If specified in CIP-0005, it'll use bech32 (e.g. Addresses, pool ids...)
• if unspecified and a short bytestring, it'll use base16 (transaction ids, metadata hashes..)
• for other arbitrarily long bytestrings, it'll use base64 as it is faster and more space-efficient.

Overall it doesn't matter that much since converting from one to another is trivial. Possibly, we could foresee an option to make it configurable so that it's possible to tweak some of those encodings at will yet, it feels "overkill" for this issue IMO.