Zoe offers sometimes have a fourth argument, offerArgs, that is an object that can take any arbitrary shape. It is currently displayed in the offer modal under "Arguments", with a Details dropdown that contains a json-like object with capData.
CapData can be challenging for non-developers and humans to read, so it should be presented in a readable format.
Description of the Design
The offer object should be transformed from cap data (makeMarshal(..).fromCapData()), so Brands, Amounts, Ratios, and BigInts are presented in a human-readable format. This could mean a list/table instead of json-like object syntax, and petnames + logos for Brands/Amounts of recognized issuers.
Someone more knowledgeable can comment on what the shape of most offerArgs will look like out in the wild, but if we can assume they are usually flat - each key resolves to a string, bigint, brand, amount, or ratio, and not an object or an array - I think it would help simply the requirements for the UI design. If offerArgs is a deeply nested object, the labels for the values could be something like foo.bar[0] or foo.bar.0.
Security Considerations
It is safer for wallet users if this data is displayed in a readable manner.
Test Plan
makeBidInvitation in the inter auction contracts leverages offerArgs and could be a good testing ground.
What is the Problem Being Solved?
Zoe offers sometimes have a fourth argument,
offerArgs, that is an object that can take any arbitrary shape. It is currently displayed in the offer modal under "Arguments", with a Details dropdown that contains a json-like object with capData.CapData can be challenging for non-developers and humans to read, so it should be presented in a readable format.
Description of the Design
The offer object should be transformed from cap data (
makeMarshal(..).fromCapData()), so Brands, Amounts, Ratios, and BigInts are presented in a human-readable format. This could mean a list/table instead of json-like object syntax, and petnames + logos for Brands/Amounts of recognized issuers.Someone more knowledgeable can comment on what the shape of most
offerArgswill look like out in the wild, but if we can assume they are usually flat - each key resolves to a string, bigint, brand, amount, or ratio, and not an object or an array - I think it would help simply the requirements for the UI design. IfofferArgsis a deeply nested object, the labels for the values could be something likefoo.bar[0]orfoo.bar.0.Security Considerations
It is safer for wallet users if this data is displayed in a readable manner.
Test Plan
makeBidInvitationin the inter auction contracts leveragesofferArgsand could be a good testing ground.