AEX-2: Explain how transaction encoded to string about aexs HOT 12 CLOSED

@davidyuk @AndreasGassmann I totally agree with you and as stated above i'm happy to add the links.

https://github.com/aeternity/protocol/blob/master/node/api/api_encoding.md
https://github.com/aeternity/protocol/blob/master/serializations.md

we can add these to url for dev reference.
Let me know if this satisfies your request.

from aexs.

Yes, perfect!

from aexs.

why the encoding and decoding of transaction is required here. this is self-explanatory.
if you have something in mind please provide the details here and we can discuss if we should add it to the aex.

from aexs.

The way what we using to encode transaction is invented by aeternity's developers and we shouldn't assume that it is obvious for everybody who reads AEX-2. I propose to just add a link explaining it.

from aexs.

"MUST", "MUST NOT", "REQUIRED" and so on even more self-explanatory than tx encoding, but you have added a link to RFC 2119. Why don't do the same with transaction encoding?

from aexs.

okay. fair enough. can you provide me a link that would satisfy this request. i would be happy to add that.

although it is not really needed as a reader might not know what "MUST", "MUST NOT", "REQUIRED" correctly stand for but will definitely know how a transaction in aeternity looks like.

from aexs.

Can you explain the last point?

from aexs.

i mean any one using aeternity esp. a dev will know what a transaction in string format means and looks like.

from aexs.

Even though encoding/decoding of txs is not directly related to this AEX, I think it would be beneficial for developers to have a link where they can read more about it.

from aexs.

definitely know how a transaction in aeternity looks like

AEX-2 reader may be a developer that is not familiar with aeternity but he needs to do something quickly with it, and if you put a link to encoding explanation then he won't need to search it somewhere else that for sure should increase conversion 🙂

what if later in aeternity ecosystem appear a new way/extension of the current way to encode transaction to string? it will make AEX-2 definition ambiguous, will be more difficult to check if particular implementation corresponds to AEX-2 or not

from aexs.

added the references. I think this can be closed. let me know if anything else is required.

from aexs.

ok, I'm closing this issue (fixed in #93)

from aexs.