Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Property names, identificators and metadata in general #222

Open
dexX7 opened this issue Jul 8, 2014 · 0 comments
Open

Property names, identificators and metadata in general #222

dexX7 opened this issue Jul 8, 2014 · 0 comments

Comments

@dexX7
Copy link
Member

dexX7 commented Jul 8, 2014

Initially intented for #216 and omniwallet/644, but I think this topic is a broader one.

The whole concept of using user defined names and categories as sole identificator was never feasible in the first place, because there is no mechanism to verify the provided data on a protocol level. At best it provides an anchor for easier recognition ("the property I'm looking for has name X and therefore is one of all properties with name X" as well as "the property I'm looking at should have name X and therefore this may be the property I intended to look at, if it's name is X"), but on the other hand this also opens the door for confusion or even scams based on name squatting.

The only absolute and reliable information is the property id and to some degree the context of the issuance (e.g. issuer's address, date, amount, ...).

It's crucial to understand that user defined metadata may only serve the purpose of falsification in this context ("it's not the property I'm looking for, because it's metadata does not match"), but cannot be used as identifiator on it's own.

Nevertheless there are several use-cases to support additional metadata in general and I think it would be awesome, if something like the "asset issuance standard" is actually established. On top I think it would be useful in some cases to not limit additional metadata to properties, but also to expand this to other parts of the system, for example addresses and users.

A few questions that come to my mind:

  1. How much metadata should be supported on a protocol level, which metadata that is and if there should be any at all?
  2. Is it required to store such data on the blockchain and if it's stored externally, what can be done to support consistency?
  3. Are there solutions that serve the initial intend of providing human readable identification attributes which are not trustless, but "good enough"?
  4. Are there existing environments that face similar problems and how are those addressed?

I think Twitter may serve as example. There are internally used unique ids used, a username which is unique and acts as user defined identificator as well as a bunch of additional user data such as profile desciptions, a picture and so on. Furthermore "high value" profiles are flagged as "verified" by a trusted third party, namely Twitter itself.

My personal opinion:

  • The sooner a shift from property names as identificator happens, the better. (hint: "txid" + malleability)
  • A property name appears to be very important for me, but maybe there are additional options on top to help to identify and recognize properties, e.g. a few colors based on the property id or identicons (also: MonsterID) which are shown on explorer websites and the clients.
  • Similar to Twitter's "verified" tag, centralized or decentralized parties may "approve" and establish a source of trust. On a broader scope this doesn't necessarily involve rating agencies, but starts with a "trusted" issuer itself.
  • I'd love to have the ability to attach metadata to addresses or properties! Remember the case where an user missed the DEx payment timeframe, posted on the forums and finally got his coins, after the issue was broadcasted via the mailing lists? Would have been much easier, if there was a small "note" attached to the seller with his email address. It would be so awesome, if masterchest.info stops to show placeholder pictures and starts to show what users submit.
  • My biggest fear related to metadata and addresses is the risk of creating some kind of "whitelist seperation" - not sure how to phrase this, but say for example users start to attach their contact data to their addresses or properties for the purpose of a message similar to "I don't want to con you, I'm real and you can call me at any time under this number". This may be desired in some cases, but it may also bare the risk of shutting out the other ones who don't follow this practise. Imagine the case where explorers start to list only approved and whitelisted users... again, this may be desired, but I have a feeling that tells me this direction is very wrong.
  • Keep the blockchain footprint as low as possible. If the data is not crucial, get rid of it and replace it by a reference and some kind of commitment, if necessary and applicable. For example this could be a link to an "asset issuance standard"-like document and a hash of this document. Providing the hash alone may be sufficient - I'm thinking about somethink link magnet links, P2P/BitTorrent or (centralized) databases here. In this case the hash may serve both as commitment as well as resource identifier. It may not hurt, if the issuer is allowed to provide a link to his own webserver as fallback.
  • In contrast to blockchain based storage there is no guarantee that external data will be available at any time, but given that user defined metadata is not "verifiable" in the first place, this may be acceptable.
  • All this needs do be balanced. It's probably not acceptable to ask every user to host his own files or to run some kind of distributed storage system, if it's just about some short names or whatever.

TL;TR: I think property names should not be used as identificator and I'd also love to attach a rich set of metadata to anything Mastercoin related.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant