Standard for additional asset information about stellar-protocol

[nullstyle]

It seems like choice A is most inline with our existing protocols, and as much as I would really like to start integrating with ipfs I'm not sure if something as core as asset metadata should be tied to a fully external and large system like ipfs

[MonsieurNicolas]

Yeah, because we can doesn't mean we should: changes at that layer will have to be supported forever and we not implement what is really needed anyways.

Also, this issue is not about arbitrary tags on arbitrary ledger entries but on assets and my point is that if we have to implement this outside of the core protocol (because of size limitations etc), we should test the water with that one implementation and see what people do with it.

[stanford-scs]

I agree with A. I like the fact that an https certificate can tie the token to a legal entity.

[paultiplady]

Given that there is an Account.data, would it make sense to have a corresponding Asset.data as well? It seems like on-chain log-based k/v storage directly tied to Assets would be useful; you could insert an IPFS link if you chose to, or just the raw values.

Adding an IPFS/IPNS link would also work for a log, but it adds a nontrivial amount of complexity to actually hosting assets that require the above token data. (e.g. the "getting started" guide would have to include "set up an IPFS node").

While it's true that you could put this in the stellar.toml, there are a couple issues with that approach:

1. it's mutable, so you can change the fine print without anyone being able to prove that it was changed
2. stellar.toml would get quite unwieldy if there were large numbers of assets issued by an individual anchor. I don't want to have to fetch the whole blob of Asset00001...Asset99999 just to get the data for Asset12345.

This latter point also applies to just putting that data in the issuer's Account.data.

[nullstyle]

Given that there is an Account.data, would it make sense to have a corresponding Asset.data as well? It seems like on-chain log-based k/v storage directly tied to Assets would be useful; you could insert an IPFS link if you chose to, or just the raw values.

I really like this idea @paultiplady. It seems pretty clear to me that the issuer would have their account reserve increased in proportion to the added data, the same as any other subentry. Thoughts @MonsieurNicolas ?

[MonsieurNicolas]

I don't think I see a problem with using the account data of the asset issuer to store additional information (there is still a need to define a standard of some sort for the schema of said data).

That said, I think the stellar.toml approach allows for a lot more flexibility: storing this data "on chain" seems more like an arbitrary decision that actually breaks if the data is more than a few bytes so we're back to storing hashes on the network anyways, so why support 2 ways when we can just support one?

Without actually knowing about the scenarios being considered for this it seems that the safest approach is to only store a few hashes with the issuer account that links to specific data/contracts off chain.

[nullstyle]

so why support 2 ways when we can just support one?

The flexibility in modelling your application on top of the stellar ledger would be much simpler to understand for consumers of the data. I'll ask as a counter: Why arbitrarily limit the stellar metadata system to accounts when implementing a polymorphic id for data fields would seem non-egregious given tagged union support in xdr? :)

The more I think about it -- I think we should probably add support for custom data attributes on trustlines as well. These meta data fields are simple and powerful ways to bind small pieces of data into the stellar ledger in interesting ways we won't foresee.

[jedmccaleb]

this was added to SEP-1: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md