Added functionality

[wmbutler]

This list could be much more useful if it contained an object for each coin instead of a parameter list:

{
    "name" : "Bitcoin",
    "symbol" : "bts",
    "uri" : { 
        "coin": "bitcoin",
        "amount" : "amount",
        "message" : "message",
        "label" : "label"
    }
}

The URI object would be particularly useful because it's required for wallets that present QR codes. These URI's don't use the symbol, they use a long name for the currency an those lists aren't easy to find freely. Also, many coin URI's have a different set of terminology for the message. Some call it a memo. So, if you could normalize this through this library, it would be pretty powerful as well.

[radiovisual]

Nice idea! I am all for making this list more useful. PR welcome, otherwise I can try to get to this sometime soon.

[wmbutler]

Maybe it should be a /v2 document in case others are using it as it? Happy to issue a PR if you can devise a way for it to be backwards compatible.

[radiovisual]

I think maybe we can generate both lists, one with more detail, and the one we are generating currently, and the users can pull in the list they want.

[angelexevior]

Hiya boyz. Joining the pack here. and great work so far.
Regarding backwards compat, If the 2 original parameters remain the same and at their positions, any added one would not break any "proper" integration.
An interim period where both co-exist, with a message to upgrade to latest version and an end-of-life for the root parameters would go a long way.

I can see many usages of the uri data, and even on top of that, consider 'protocol' (POS, POW etc), 'Algorithm' if mined (POW).
Willing to contribute the pitiful spare time i got ;)

[radiovisual]

@angelexevior thanks for the kudos! :)

How do you see the current list co-existing with this list that was proposed by @wmbutler above?

The current list has a structure of:

{
  "42": "42 Coin",
  "300": "300 token",
  "365": "365Coin"
}

whereas a new structure was proposed of:

{
    "name" : "Bitcoin",
    "symbol" : "bts",
    "uri" : { 
        "coin": "bitcoin",
        "amount" : "amount",
        "message" : "message",
        "label" : "label"
    }
}

As far at the API goes, I also see this being a problem if we try to keep backwards-compatibility (I wouldn't want to set a custom getter for each cc):

cryptocurrencies.BTC;
//=> 'Bitcoin'

So I am not seeing a way to make these two lists compatible, unless I am missing something? I think having two lists generated, and the user can decide which one they want to use is fine by me, but I am happy to consolidate the lists if there is a way to maintain backwards-compatibility.

With all of this said, each time we do a release we bump the major version because the list changes pretty drastically each time we build it (and I can see use-cases where some apps are relying on old versions of currency names or symbols), so in a way we don't have to be so careful, we could change the API in a new major version.

[angelexevior]

Apologies @radiovisual. Spoke before switching my brain into gear.
I've just seen the original json. I was with the idea we already had the name: "actualname", symbol: "... from the comments above.

Well, if we want to go forward with this, the only way is to introduce a separate V2.0 and announce that the original json will not be maintained anymore, thus keeping the existing integrations alive until they switch to the newer version.

What say you!

[radiovisual]

@angelexevior, another option is just maintain a few different lists, and the user just pulls in the list they need. There are use cases for having different types of lists (such as #16), so I would not be against having different lists, but then again, its more work. Perhaps there is some value in keeping one list, and then let the user generate their own ideal list if they need something a bit more stripped down. Either way is fine with me.

[wmbutler]

Two lists is probably not a great idea. What about this?

{
    "bts" : { 
      "name" : "Bitcoin",
       "uri" : { 
          "coin": "bitcoin",
          "amount" : "amount",
          "message" : "message",
          "label" : "label"
       }
    }
}

[radiovisual]

@wmbutler I like your proposed structure

{
    "bts" : { 
      "name" : "Bitcoin",
       "uri" : { 
          "coin": "bitcoin",
          "amount" : "amount",
          "message" : "message",
          "label" : "label"
       }
    }
}

👍

[angelexevior]

D'accord @wmbutler @radiovisual
Just had a thorough look in the code. Correct me if i'm wrong but the list is just a flat file, not generated by someone automatically(or semi).
A good way forward would be to centralize the list db into something we can utilize to generate any sort of list we want... Perhaps a mysql, a csv, even a google spreadsheet (Use APIs to pull data), so we can add any sort of additional data, and generate any list structures we see fit.

Also, consider adding a small API framework to it (REST) for a wider reach.
*I can suggest a framework i deved in the past.
**I would volunteer to host the API and mini-site

[radiovisual]

@angelexevior

Correct me if i'm wrong but the list is just a flat file, not generated by someone automatically(or semi).

This list is generated semi-automatically by running npm run build. It grabs the latest currency data from the cryptocompare API to generate the flat list.

A good way forward would be to centralize the list db into something we can utilize to generate any sort of list we want

This is one of the utilities of a flat list like this, where anyone that pulls this list into their project can use it to generate anything they might need. Feel free to build/host anything you like that uses this list (help is always welcome) in a separate repo so we can still keep this flat list a small dependency. I would love to see some tooling spring up around this list.