Guidelines Question: make it easier to upgrade the table

[jbenet]

STUB issue. cc @diasdavid @mikolalysenko @chriscool @kubuxu @lgierth

[jbenet]

This was an issue about giving implementors guidelines on how to make it easy for users to replace the table with a custom one, or just a newer version of the table.

This is relevant because sometimes implementations will go into dependency graphs and it would be unideal to have to change all the deps to change a table.

Concerns:

• Convenience: should be easy to change tables across many libraries.
• Security: This should not be static process-wide, otherwise it would be a serious attack vector. Instead, libs that are users of multihash SHOULD expose a way to grab the multihash module or provide alternative tables.

[daviddias]

One idea is to have an official issue table, signed that is loaded and verified on boot, so that there is no chance for a change of a hash that is recognised by every application.

For all the other codes, application specific, it would be good to provide several ways to add in, such as:

• multihash.table.add(, ) - for single instance use
• multihash.table.add(path) - so that every instance can load the same table
• env variable set with a path or an ipfs hash - same as above, but easier to instruct all the multihash instances in our code dependencies