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.

                                                            Ho & I agree that off-chain data posting is a must have. Both functionalities are complementary and absolutely useful. I didn't intend to oppose them.

                                                            8 days later

                                                            Show some creativity. You have another 64 key, 64 value = 128 bytes for every manageData operation that you attach to your transaction ?