Looking at these two different cases separately.

In supply chain, I need to put the tax invoice with some key info like company name in the memo. It is a common case in China not only in supply chain management. A team in a travel agency also have the same requirement.

Is the data going into the memo for the benefit of the sender or the receiver?

What you're describing is familiar. Orders and payments move through systems; the the client information, the vendor information in the procurement system, the purchase order number, the invoice number, the payment's check number and depending on the jurisdiction, the tax information has to be tracked and linked together so the accounting systems, inventory system, and manufacturing execution system of the multiple companies and governments involved can keep track of what's owned and to whom.

Is what you're describing putting the data structures associated with the value transfer / ledger manipulation that is meant for the non-ledger systems into the memo field for storage in the ledger. So the requirement is data storage and message passing of arbitrary data. Is this something we should expect to put in a generalized wallet application? Should any Stellar client be able to encode the appropriate data strcuture and decode the data anohter client has placed on the ledger?

I will say I expect that our wallet applications should be able to utilize many of the features defined by SDF, but this message passing and handling and the data storage seems like a little much for an application on a phone someone uses to check their balances and pay for coffee. Or is the expectation going to be that this would be a custom application with access to a funding wallet?

Am I missing anything in this use case?

A exchange called Julang, want to put some op_code in the memo. So it can connect to their high performance trading system.

I have no experience with high performance trading systems, so please let me know if anything I'm saying doesn't match up.

The intent here seems to be about messaging--sending instructions to the trading system. Will all the op-codes be assoicated with a value transfer or ledger manipulation on Stellar? Or will there be any instances where an op-code is sent into the trading system that doesn't involve changing a balance of some asset, control of an account or the properties of account on Stellar? Is the communication channel one-way or two-way?

As an exchange, are they "living out of Stellar" or is the integration more them being a gateway between Stellar and their trading platform?
And again, will participating in this traffic be something that's expected of any random wallet?

2 months later

liangran Hi quick question: is there a way to Deposit/withdraw CNY via Ripple using stellar?
I read a blog that you mentioned something about it.
Actually you wrote this:
RippleFox is an anchor in China. We issue CNY and educate people to use Stellar. People can deposit/withdraw CNY using alipay/bank card.

We will do more in the coming days.
1. Deposit/withdraw XRP
2. Deposit/withdraw CNY via Ripple

Can you please guide in how to Deposit/withdraw CNY via Ripple using stellar?

Thanks

    a year later

    Now we use IPFS for managing some attachment in Stellar private network and problem is that our file address in IPFS is 48 Bytes. really 32 Bytes is too short for memo in stellar and we suggest to increase it to 1KB or keep it in TLV format.
    Really we need to save some evidence on Ledger and off-chain information ( Compliance Protocol and Federation and ....) is not referable.

    Thanks

      msamadi

      Raw IPFS CIDs are 32 bytes. Don't store the multi-format address, store the SHA-256 hash directly.

          dzham
          We have our Header and salting parameter on SHA-256 has, so we need at least 48 Bytes. So we have two options now:
          1- Make lookup table outside and keep SHA-256 of our String in MEMO
          2- Apply this change directly on our fork.
          also if we need to attach more than a file in one transaction, we couldn't handle it now, So I suggest to use TLV format and define new MEMO type for it.

          Regards,
          Samadi

              sbsends
              Generally is good Idea, but why you limited to 64 Bytes ? I suggest to extend it as TLV format and define new memo type as MEMO_TLV with maximum 1K size.

              Regards,
              Samadi

                msamadi also if we need to attach more than a file in one transaction, we couldn't handle it now, So I suggest to use TLV format and define new MEMO type for it.

                You can create a directory with all the files in, and send the CID of the directory.

                    dzham
                    It's good Idea, but force us to manage our files in specific structure that I don't like it.

                        msamadi

                        It's how IPFS deals with file hierarchies. A directory node is basically just a file that lists the filenames + multi-hashes of its content. Not exactly rocket science.

                        Unless you make the cost of adding a memo dependent on its size, I don't see 1024 byte memos as feasible. People will just abuse it, since IPFS memos would be up to 32 times cheaper than all the other types. Everyone would just use IPFS memos for anything, and then not have to worry about sizes "at all" anymore.

                            dzham

                            What's meaning of abuse ? customer needs to keep some information on-chain and it should be useful as evidence of financial article. If we want to keep all information (bigger than 32 bytes ) on IPFS, why we should use DLT? as I know IPFS couldn't provide enough trust.
                            Also IPFS has own overhead and increase operational cost.

                                I assume abuse mostly refer to spam / unconscious use of the network functionalities and is related to its cheapness: What is cheap is abundant and we're quick to waste resources right?

                                I think bigger data fields are out of question due to Stellar ambitions: not every project do it the same way but basically we don't know how to combine together low fees, high transaction output, wide adoption and large storage capabilities. Some technologies like sharding may end up giving us a solution but we're not here yet.

                                But clearly Stellar needs an on-chain messaging system so at least people can use their custom network as a decentralized database. On main-net you'd pay one basefee/64b to pack data so it's unlikely to generate as much abuse than other functionalities such as trade or payment which are cheaper. But if people are willing to pay for it then why not let them do so? I mean, how is it less legit than eating space for trading offers, payment, asset issuance and so on?

                                  msamadi as I know IPFS couldn't provide enough trust.

                                  You use IPFS because it is a content-addresseable filesystem.
                                  A hash will always correspond to the same content. That is the trust you put into it.

                                  Change the file, and you get a different CID.

                                  IPFS doesn't inherently solve hosting, but that's what pinning is for.

                                  msamadi Also IPFS has own overhead and increase operational cost.

                                  Yes, but you pay for it. Not everyone else, who doesn't care about you customer information.

                                  msamadi why we should use DLT?

                                  • you have some content-addressable data that you want to associate with a financial transaction
                                  • you have some data you want to timestamp (proof-of-existance)
                                  • etc, etc

                                          MisterTicot I mean, how is it less legit than eating space for trading offers, payment, asset issuance and so on?

                                          Because offers, payments, etc, are there to support the basic functionality of the network. Memos are just auxiliary, application specific data. 64 bytes might be OK if there's anything that really needs it. 1024 is ridiculous, especially when only suggested out of laziness. (E.g., I can give you a 32 byte SHA-256 hash that corresponds to a directory node that's the root directory of my laptop hard drive. 32 bytes. That's all it takes, folks)

                                            dzham

                                            Of course IPFS has some facilities to manage files decentralized and addressable, but the question is that why for any small information we should use IPFS as parallel of blockchain ? why we should use two decentralized systems as same time ?
                                            Stellar forced us to use IPFS or any similar solution for any information more than 32 bytes, and this condition make complicated ecosystem for service providers.
                                            My idea is that 32 bytes is not enough for memo and should be upgrade as flexible size field by TLV format, and make new memo type as MEMO_TLV that cover developer requirements.

                                            My understanding from Trust is: non-reputation, Integrity and confidentiality as same time. can you advice, How IPFS provide these requirements ?

                                                msamadi

                                                Again, IPFS files are immutable. You change the content, you change the hash. Any time you reference a specific CID, you can be sure that the content is what you expect it to be.

                                                Where's the limit for how much application specific data to allow in memos, when every byte added has to be stored in perpetuity? At what point do we rename the whole thing to Dropbox?

                                                    dzham

                                                    ?
                                                    I suggest to rename Stellar to IPFStellar.
                                                    I think Immutability and Trust are two different things.

                                                        msamadi

                                                        They might be different things, but thanks to the immutability YOU CAN TRUST that the data doesn't change.

                                                          22 days later

                                                          Definitely agree with @dzham. 1024 bytes does not seem aligned with Stellar's current implementation of the memo field. @msamadi, basic IPFS nodes handle hash generation for you if ease of use is your concern.

                                                          EDIT: @MisterTicot what are the benefits of on-ledger messaging? Can you guide me through the rationale?

                                                          IMHO off-chain messaging is important in addition to on-ledger comms because it:
                                                          1) Provides privacy (no visible message exchange / message lengths).
                                                          2) Increases communication speed (micro-payment channels).
                                                          3) Allows for multiple communication protocols/modalities.
                                                          4) Reduces auxiliary data on-chain (e.g. exchanging preauthorized transactions for "smart-contracts". A reference (hash) of the communications can be stored on-ledger if public validation is required.

                                                            sbsends

                                                            I use on-chain messaging to trustlessly coordinate multisig TX in oc-multisig.

                                                            You could use it to post IPFS hashes along with transactions, to build trustless voting systems or more generally to build various kind of dApp that have to pass data.

                                                            What we can do with it is mostly an unexplored area. I envision it will be a major component of dApps in the future when each dApp will actually run on top of its own custom network (as a side-chain). In this setup data storage will not be so expensive anymore.