Invent schema for specifying the identifier property in _data about tcr

[hodkov]

Here is the IPFS file format for TCR items (in particular for TCR of TCRs) to the review.

IPFS file format for TCR of TCRs items

File type: JSON.

{
  "address": "0x81e1269708582ae17560b6acc0f45d0416df8d68",
  "name": "My TCR",
  "fields": [],
  "localization": {},
  "customization": {},
}

• address - TCR contract address, required
• name - human-readable TCR name,
• fields - list of TCR item properties’ description (Field),
• localization - localization config,
• customization - ui customization config

Field format

{
  "name": "myProp",
  "type": "String",
  "default": "My property",
  "required": true
}

• name - property name, string;
• type - property type, one of: String, Number, Boolean, Any or JSON object with Array or Object description (ObjectType or ArrayType format);
• default - default property value;
• required - boolean, is property required?

ObjectType format

{
  "fields": []
}

• fields - list of properties’ description - Field format

ArrayType format

{
  "type": {
    "fields": [
      {
        "name": "myProp",
        "type": "String",
        "default": "My property",
        "required": true
      }
    ]
  }
}

• type - property type, one of: String, Number, Boolean, Any or JSON object with Array or Object description (ObjectType or ArrayType format);

Localization format

{
  "en": {
    "registryName": "My Super TCR",
    "apply": "Apply",
    "buy": "Buy",
    "candidate": "Candidate",
    "applicant": "Applicant",
    "tokenHolder": "Token holder",
  },
  "de": {
    ...
  },
  ...
}

Object with properties - language codes. Every property contains key-value pairs of localized strings.

Open question: should we store localization config file to IPFS? Or should it be a link to a third-party service? IPFS over IPNS?

Custiomization format

{
  "defaultTextColor": "#000",
  "defaultFont": "Arial",
  "headerColor": "#FFF",
  ...
}

An object with key-value pairs of ui properties.

Open question: should we store UIconfig to IPFS file? Or should it be a link to a third-party service?

[Kmoneal]

https://github.com/kangarang/tcr-ui/blob/master/docs/IPFS.md#prospect-park-ipfs-conventions

[shrugs]

Making the identifier constant id would be helpful.

What's that multiurl spec that can use used to standardizing strings that include the information "if you support ipfs, here's the ipfs hash, otherwise here's a web url that responds in json" mutli-url? multi-schema? something like that

[kangarang]

@shrugs @skmgoldin i prefer identifier over id only because it likely will not be a number. unless im missing something!

@hodkov thank you for posting those ipfs file formats. it's much larger than the scope of this issue; however this is still really great. i've been learning ipfs recently so it's nice to see it in the context of what i'm currently working on.

[kangarang]

@shrugs i've been looking all over for what you mentioned, but still am not sure about it. was it multiplexing?

[kangarang]

@hodkov, i like the localization config. i dont think we need to store ui config data in ipfs. frontend apps can manage that in their build. the Field part is still a bit hazy to me. could you expand on that please? are fields the transaction arguments?

[shrugs]

@kangarang honestly can't remember the name, it's very infuriating 😢

I'm not partial to id vs identifier, just as long as everything gets a guid of some sort

[kangarang]

i just realized i was way overthinking the implementation, trying to fix problems that weren't even there hahah