While adding Nano (#109) support, I think I ran into some ambiguity around what OWS intends sign_message to mean, across chains.

I may very likely be misunderstanding the original design intent, or the implementation may simply have drifted. I also see several other open Issues with "sign" in their title... Either way, this seems worth clarifying before more chains build on possibly different assumptions.

Today, sign_message appears to fall into a few buckets:

Standardized off-chain message signing

• EVM: EIP-191 / personal-sign
• Bitcoin: Bitcoin Signed Message
• Tron: TRON-specific personal-message prefix
• Sui: personal-message intent hashing

Hash-then-sign of arbitrary bytes, but without an obvious ecosystem-wide message-signing convention

• Cosmos
• Filecoin
• Spark

Raw-byte signing with no special envelope

• Solana
• TON

Explicitly unsupported, because no clear canonical convention has been chosen yet

• XRPL
• Nano

So the same sign_message method can currently mean:

• “sign using the chain’s recognized off-chain convention”
• “hash arbitrary bytes and sign”
• “sign raw bytes directly”
• or “error: unsupported”

That may be intentional, but if so it would help to document it explicitly. If not, it may be worth tightening the interface contract a bit.

Questions that seem worth clarifying:

1. Is sign_message meant to be a user-facing cross-chain off-chain signing primitive?
2. If yes, should it only exist where there is a recognized ecosystem convention?
3. If not, is it meant more as a low-level arbitrary-byte signing utility escape hatch?
4. Should transaction/block signing on one hand, and generic off-chain message signing on the other, remain strictly separate? (sounds that way)
5. Is it acceptable for some chains to expose raw-byte signing under sign_message, or does that falsely imply interoperability that does not really exist?

The current behavior leaves room for contributors to make different assumptions..