Hash memo does not follow the spec
The spec says that hash
memos should be base64 encoded, at the moment the service returns the hash hex encoded. The service is basically broken with software that expects an hash memo.
Comments (8)
-
repo owner -
repo owner Looking for examples of hash memos is hard. It does not look like many people use this. In fact I checked and you’re the first person who tried to register such a hash in our federation system.
But as a reference, even the official Stella Lab transaction builder takes the “32-byte base64 hash” from the specs as meaning a 64 characters hexadecimal string.
-
Sorry for the late reply, I didn’t have an account. Also sorry if I came off too aggressive in the first comment but I couldn’t edit it.
It seems to break Keybase, it will correctly fetch the memo as hex but then when sending it says
invalid federatino hash
.I agree it’s confusing because most examples and SDKs use hex strings for hashes, but the spec says to use base64 and horizon returns the memo in base 64.
-
repo owner So would it be better if I accept both a 64 character hex string and a 44 character base64 type string for the hash memo? That would let the owner of the federated address decide what format to use.
-
Yes, that sounds great! Thank you.
-
repo owner OK so I just pushed a fix that will let you register a string representation of a 32 byte long base64 hash (example:
MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDE=
) -
It now works perfectly, thanks. You can close the issue.
-
repo owner - changed status to resolved
Fixed in commit 255984c
- Log in to comment
Hello,
Could you give me an example of software broken by that behavior?
The docs are fairly sparse regarding hash memos and from what I could see in the python stellar SDK, it accepts hash memos in either binary or hex-string formats. I currently validate the hash memo field as a 64 character hex string representation of a 32-byte base64 hash. Would it be better to also accept a 44 character string representation of the hash?