owned this note
owned this note
Published
Linked with GitHub
# Regen Cosmos SDK Architecture Review
**Date:** Fri Jan 29, 2021
**Attendees:**
**Zoom:**
https://us02web.zoom.us/j/86444484091?pwd=T2tabFhqaFVSYkwyM0cycmdITjJCdz09
*This meeting will be recorded.*
## Agenda Items
- [ ] Discussion about `SIGN_MODE_TEXTUAL` [#6513](https://github.com/cosmos/cosmos-sdk/issues/6513)
- [ ] ADR028 - Public Key Addresses [LAST CALL]
- [ ] ADR038 - State Listening [LAST CALL]
- [ ] Rosetta API balance tracking feature
- [ ] Bank Module Refactoring (slightly related to Rosetta API balance tracking) - Aaron
## Notes
- `SIGN_MODE_TEXTUAL`
- Aaron: We want to have a different textual format for signing protobuf messages on hardware wallets (like Ledger Nano's)
- Zaki and I had been proponents of sending formatted strings to the ledger app, and then ledger would just need to consume text lines, presenting them to users, without much need for understanding the text specifically
- Juan from Zondax (works on Ledger hardware app) had raised some concerns about Devs not knowing proper hardware constraints for presenting such text (e.g. field's key length)
- Juan: I'm pro a textual signature mode, but my concern is that SDK users could misuse this, and might not completely express what the payload contains
- e.g. if there are some fields that have important meaning, but get left out by some developers (e.g. fee, chain_id, etc.)
- Ledger historically has been more involved in deciding which fields get presented to users, etc.
- Aaron: We could also separate what is written, from how its generated
- Gerry: another example is Tezos, you still send the exact payload to the device, but it is binary (not json), and in the ledger we have a parser that is able to generate human readable text on that side
- Robert: another concern is that this leaves more responsibility on the developer (adding a custom function results in the SDK developer needing to ensure that each input maps to a unique output - won't create conflicts on two different messages)
- Aaron: we've already discarded the tezos approach due to difficulty with having proto definitions & a full proto implementation on the Ledger side
- Juan: We need to cover cases from hobby projects that create sign_mode_textual with something like "SIGN ME PLEASE"
- Aaron: There is the possibility of using reflection (See **Ex 2** below), but we lose the ability to support localization
- Aaron: The workaround for localization would involve translation bundles (that potentially live on the state machine), with mappings between field names and localized strings
- Gerry: The issue here is that we would need to trust the javascript client to give the correct translation bundle
- Aaron: What i'm proposing intends not to be vulnerable to that, as the state machine would take care of using the translation bundle to translate back from textual signed content
- Juan: one hard limitation is that we only can work with limited ASCII characters (not extended ASCII) - 7bit ascii
- Specifically ascii codes 32 - 127
- Robert: Maybe we can agree on one thing - Do we need that what you sign is what you see?
- Seems like there is rough alignment that ledger will sign human readable bytes (potentially together with protosignbytes), and signature verification verifies that human readable text corresponds correctly to raw sign bytes
- Robert: What's the issue with using proto json?
- Aaron: We had wanted something more human readable than JSON. Zaki and I had wanted to have SDK developers create their own format strings, but Ledger folks have a concern about SDK devs abusing this (which is valid)
- Juan: The main concern, and reason I didn't like JSON was that it was hard to tokenize nested fields & types (& we would need to flatten them to show in the UI)
- Juan: The main constraints we should ensure are:
- level of nesting should be limited (if possible)
- limit on character set
- formatting is a bit irrelevant, but we should try to keep the total text below 4kb
- http://gibson042.github.io/canonicaljson-spec/
- https://github.com/regen-network/canonical-proto3#json
- Gerry: The main point is that we need to have some human readable blob that enters into the device
- Gerry: The best example is how someone verified that IBC Msg Transfer worked without us having to do anything on the Ledger side
- Aaron: So if we just switched to protobuf JSON, would that be OK for the Ledger?
- https://github.com/Zondax/ledger-cosmos/blob/master/docs/TXSPEC.md
- Juan: One other thing i just realized - the use of protobuf means any user can change the schema on the fly.
### Ex 1
```
HGSD3t798dsgb32578sdgh3u8w3bbsdg3gsbg=
Send 10 ATOMs from cosmossdkjghweqiuh to cosmossdgjsdgkkhsdg
Send 15 ATOMs from cosmossdkjghweqiuh to cosmossdkjg2et78sbdg7sdg
Create Proposal
From: cosmosukjdwgh38dgsdgh8
Deposit: 10ATOMs
Send
From:
To:
Amount:
```
### Ex 2
```
cosmos.gov.Msg/SubmitProposal -> "Cosmos Gov: Submit Proposal"
deposit_amount -> Deposit Amount:
```
## Follow-ups
-