Defining contract standards for Filecoin

[anorth]

As it becomes possible for developers to target the FVM (ahead of the actual enablement of deploying user contracts), interoperability will be benefitted by defining a few standard contract interfaces.

To kick this off, I'm about to push a FIP draft for a fungible token standard, adapting Ethereum's ERC-20 to Filecoin. This is as much to stimulate discussion about how we should define such standards as it is about defining this particular one (which is a straightforward rip-off).

This discussion topic is a place for the meta-discussion about how we will define contract API standards:

• Will we use FIPs (and hence FIP numbers) in the same way that ERC definitions are incorporated into the EIP process?
• What language will we use to define the APIs (and ABIs)?
• How much will we benefit from adapting widely-used APIs from elsewhere (like ERC-20) vs developing our own, informed by issues since discovered with such original standards?

See #277 for discussion of the content of that specific proposal.

I will be equally pleased to merge my draft fungible token standard as is or by completely reworking it into a different language and/or interface, so long as we land with a clear and low-friction path to defining many more such contract standards in the near future.

cc @raulk @Stebalien @laudiacay @nicola @Kubuxu

[kaitlin-beegle]

To the first point, I like the idea of FRCs (so to speak) be initiated as FIPs, which is also how Ethereum manages the EIP/ERC process. I think this will be organizationally easier to manage; FRCs and FIPs could be kept in the same place and clearly distinguished from each other, while closely mirroring the Ethereum process will make Filecoin governance more accessible to new devs.

I am curious what others think about the approval process for FRCs, however. The de facto community approval process we use for FIPs may not be as appropriate for documents that are intended to be written by developers, for developers. Perhaps Core Devs ought to be responsible for formally 'approving' proposes FRCs, after a set community deliberation period?