Write up feedback from @Schwartz10

[jimpick]

• Zoom session on 2020.03.01 with @Schwartz10
• Quick review of the examples at https://github.com/filecoin-shipyard/js-lotus-client
• Looked at how Lotus JSON-RPC API is used in prior work:
  • https://github.com/openworklabs/lotus-block-explorer/
  • https://github.com/openworklabs/filecoin-web-wallet
  • https://github.com/openworklabs/filecoin-message
  • https://github.com/openworklabs/filecoin-address
  • https://github.com/openworklabs/filecoin-message
• Shared ideas about what a higher-abstraction Client API might look like
• Discussed wallet integration in browsers

[jimpick]

Meta: For these feedback summary notes, we're going to keep the issues open in GitHub for a week for visibility, and then close them.

[mishmosh]

@jimpick Can you add more detail here? Imagine someone wasn't at the session, but wanted to learn that you learned from it. Especially ideas about higher-abstraction API and wallet integration in browsers.

[jimpick]

I'll just add a little bit more ... it was a wide ranging conversation and difficult to summarize everything.

The work that was done with the filecoin-web-wallet project was informative. They provide an API that wraps the Lotus Node JSON-RPC call, but depending on what "wallet provider" plugin is being used, diverts the wallet-related calls to use wallets that are outside of the node itself (e.g. a hardware wallet or a web extension based wallet). Here's some of the code they wrote to do that:

https://github.com/openworklabs/filecoin-web-wallet/tree/primary/WalletProvider

A nice-to-have feature for a higher-abstraction API would be to have built-in support for pluggable modules that would support things such as alternate wallets.

[Schwartz10]

Adding my notes too @mishmosh @jimpick

--

We talked about some of the patterns in the Ethereum ecosystem that developers are familiar with. We think it makes sense to emulate some of those patterns in the Filecoin space because it would presumably remove frictions associated with working across both ETH and FIL ecosystems (and presumably other blockchains too). It'd be great if developers could come into the Filecoin space feeling like they already know how the moving parts are working.

Some examples of the Ethereum patterns that could make sense:

• method abstractions to make certain complex actions easy to do from JS. web3.js and ethers.js.
• maintaining flexibility within a library without adding too much to the bundle size. This contributes to having an appetite for a "plugin" system because developers can plug and play with subsystems that are relevant to their applications (for example, the Filecoin web wallet does not need any mining, or client rpc calls), so it wouldnt make sense for us to require a library that is packed with helpers, utility functions...etc around those method handlers. inspiration.

One exciting aspect of this library is that it can serve as a building block for other important applications and developer tooling such as:

• A dapp browser or browser extension that enables developers to easily build Filecoin applications that rely on digital signatures, without implementing private key management on their own.
• A notification system for listening to new on-chain events.
• A Truffle Contract-esque ORM tool that helps developers en/decode parameters for sending messages.
• Boilerplate/example Filecoin application codebases as Hackathon starting points.

We also touched on some challenges:

• what are the API interfaces that make sense and give developers the functionality they need to build applications?
• what do developers actually need?
• how do we handle errors (once we dug deeper into this question, it actually gets quite complicated).
• websockets vs http
• how should we prioritze support for other environments (outside of browser) like node, CLI, React Native, electron..etc

Some next steps:

• Create 2-4 example READMEs for different library interfaces and method abstractions. Jim and I both are keen on the concept of "readme driven development"
• Implement 1 or 2 proof of concept versions of the JS library according to the README documentation.
• Example usage of these libraries in the wallet or other applications would allow us to look at how "clean" the code is when used in another application.