wallet action, inter protocol data is wrapped in 2 JSON.stringify layers

[dckc]

Describe the bug

The .action field of MsgWalletSpendAction is JSON.stringify(capData) where capData includes a .body that is already JSON.stringify ed.

Senders pay by the byte, so the extra quoting costs.

To Reproduce

Steps to reproduce the behavior:

1. generate a spend action; for example: inter bid by-price --price 7 --give 0.003IST --generate-only --from k1 >spend-action.json
2. See lots of escaped quotes:

{"body":"#{\"method\":\"executeOffer\",\"offer\":{\"id\":\"bid-1688229012779\",\"invitationSpec\":{\"callPipe\":[[\"makeBidInvitation\",[\"$0.Alleged: BoardRemoteATOM brand\"]]],\"instancePath\":[\"auctioneer\"],\"source\":\"agoricContract\"},\"offerArgs\":{\"maxBuy\":{\"brand\":\"$0\",\"value\":\"+1000000000000\"},\"offerPrice\":{\"denominator\":{\"brand\":\"$0\",\"value\":\"+1\"},\"numerator\":{\"brand\":\"$1.Alleged: BoardRemoteIST brand\",\"value\":\"+7\"}}},\"proposal\":{\"give\":{\"Bid\":{\"brand\":\"$1\",\"value\":\"+3000\"}}}}}","slots":["board05557","board0257"]}

Expected behavior

One layer of JSON.stringify should suffice.

For example, send the .body and .slots as separate protobuf message fields.

Platform Environment

agoric-upgrade-10 mainnet

[gibson042]

related conversation: endojs/endo#1402 (comment)

[dckc]

a related PR was closed for lack of motivation:

• feat(marshal): cheap capData stringify and parse endojs/endo#1558

this perhaps adds some motivation

[dckc]

Explorers

The contract explorer bounty is yet another context where I don't look forward to explaining the double-quoting convention.

Protobuf

Cosmos Explorers already have to deal with protobuf. Not to mention indexing / query stuff such as subquery:

• Agoric Subquery starter subquery/cosmos-subql-starter#37

In the OCapN context, I did a little playing around with protobuf encoding for passables:

• passable.proto

Single-level JSON

I just worked up an idea that I had recently:

• feat(marshal): encode capData in 1 level of JSON endojs/endo#1804

Comms / DeliverInbound format

Another option would be the format used in the Comms Message format used in DeliverInbound messages:

• [${slots..};${methargs.body}](deliver:${remoteTargetSlot}::${slots..};${methargs.body})

for example: "1:0:deliver:ro+1:rp-40;#[\"getConfiguration\",[]]"

[dckc]

In endojs/endo#1804 (review) , @mhofman writes:

I would so much rather we properly split encoding from serialization for marshal, as discussed in endojs/endo#1478.

What would that look like for the offer example above?

Would it involve passing a complex object (requiring lots of allocations) through the swingset kernel rather than a body string?

[mhofman]

Would it involve passing a complex object (requiring lots of allocations) through the swingset kernel rather than a body string?

Potentially, unless we have an optimization of not parsing a subset of the json, which is what @gibson042 and I mentioned we needed help from the parser for. In this PR you effectively implement that optimization for a subset of CapData json shapes. I'd prefer to take the approach of specifying the new CapDate tree format, and separating the concern of avoiding the parsing of the body tree as a future optional optimization.