Snap should only access the private key if the RPC endpoint needs it.

Present the private key only in a copyable ui element.

This must be solved mostly on the iso-filecoin side, the snap just need to handle timeout errors properly.

tiged and pnpm are new to me, so this may be an easy workaround. This happened while trying to run the demo following steps here https://github.com/filecoin-project/filsnap#checkout-examples

The clone command may be missing a --recurse-submodules argument via wevm/wagmi#2496

We should add a description of what is actually happening here. Its intuitive enough for seasoned users, but if we want to be more affective at onboarding and keeping users on task, a short description and links would be helpful.

We could also detect when TESTNET is selected and link to how to fund your testnet wallet with a faucet

As mentioned in #1 support for the following FVM transactions is needed, as confirmed by @honghaoq from the FVM Product team:

Top priority:

• Send from f1 to 0x/f410
• Send from 0x/f410 to f1

The above would help resolve current issues from users trying to send to/from FEVM wallets and Coinbase, which currently requires complex workarounds using a Glif Burner Wallet or FilForwarder contract.

Question:

• Will the seed phrase for a native f1 and 0x/f410 wallet be the same?
  • (i.e., do they have different derivation paths/SLIP-0044 using the same seed?)

Related features to support:

• Create a new 0x/f410 account
• Export keys from 0x/f410 account
• Import keys from existing 0x/f410 account
• Use Filecoin Eth JSON RPC
• Gas for Eth JSON RPC Tx's
• Ledger support for 0x/f410 and f1??

From MetaMask Snaps team:

Screenshots are now live on the directory. Please send in your images so we can add them. Here is an example https://snaps.metamask.io/snap/npm/solflare-wallet/solana-snap/
Here are the guidelines.

We want to support sending FIL from a 0x/f410 address to f1 as explained in #8.

It’s already possible to transfer FIL from an 0x address created in MetaMask to an f1 address using the FILForwarder contract with Glif as explained in this article.

As discussed with @hugomrdias, we should implement the same thing in the demo that Glif does and call the FilForwarder contract running on FEVM from the demo using the native MetaMask API (i.e. bypassing the snap) in order to prevent duplicating MetaMask functionality in the snap.

This would create a prompt like this in MetaMask:

Adapter

Add support for transferring FIL from an 0x address created in MetaMask to an

• f1 address
• 0x/f410 address

Demo

• Update UI

Related: #11

Is your feature request related to a problem? Please describe.

The URL home of the app has already changed once. It's currently hosted on Fission's domain, but they're shutting down.

Describe the solution you'd like

The URL home of the app could be Github pages.

Benefits:

• Build trust that the site has not been fucked with (inasmuch as you trust Github)
• Has a pointer to the source code built-in to the URL itself
• Doesn't require whoever is developing it to also be responsible for hosting it

Describe alternatives you've considered

We've tried hosting it on the URL of several companies who were paid to develop it, which has resulted in an unstable URL.

Additional context

Follow-up issue will be filed for moving to an app-specific domain for DNSlink+IPFS which we can propose to be managed by the Filecoin Foundation.

Will add screenshots soon

Main metamask connects dapps to a specific address, the snap doesn't all address may be exposed by just changing the derivation path.

This may require a bunch of work to restrict addresses per origin given that account derivation is done programmatically (from the dapp) and not through the UI.

Steps may be to:

• specific derivation API endpoints to create and get accounts
• these endpoints need to save some state to restrict dapps

From MetaMask Snaps team:

A new version of transaction insights will soon be implemented altering how insights are fetched. You may need to update your Snap logic; please review the detailed discussion.

Hello snap devs! For launch it is very important that you update your dapps to stop detecting MetaMask Flask. Instead, you should detect for the existence of the Snaps API so your dapp is ready to work with the stable release. This will work with Flask and with the stable extension.

We have updated our documentation with a guide on connecting to a snap from your dapp: https://docs.metamask.io/snaps/how-to/work-with-existing-snaps/

However, you may encounter issues when a user is running multiple wallets in the same browser (such as Phantom and Coinbase Wallet). I have published example code for working around these issues here: https://github.com/Montoya/snap-connect-test

Please reach out if you have questions or issues with your dapps.

Describe the bug

If I connect to the app with an account, and then in MM switch accounts, the app should reinitialize itself instead of leaving previous-connected account up.

To Reproduce
Steps to reproduce the behavior:

1. Connect to an account
2. Open MM
3. Switch to a different account

Expected behavior

The app reinitializes, shows the 'connect' button.

Actual behavior

The app does not change, still shows information of previously connected account.

Code Sandbox link from readme not working

We want to add a few people for basic UI, docs, and description updates.

@eshon please list the GitHub accounts other than yourself that should be added.

@metamask/snaps-types is now superseded by @metamask/snaps-sdk

https://github.com/MetaMask/snaps/blob/7d9c2f4a24dc440c568133a4a5f48bece07595df/packages/examples/packages/get-file/CHANGELOG.md?plain=1#L11C8-L11C27

When this happens, should go through and update all type references throughout snap, adaptor, filsnap-adapter-react etc..

https://filsnap.chainsafe.io/
Pressing "connect to metamask" button results in

inpage.js:1 MetaMask - RPC Error: Error while running snap 'npm:@chainsafe/filsnap': Cannot add property default, object is not extensible 

MetaMask Version
10.31.0-flask.0

Chrome logo
Google Chrome
Version 113.0.5672.92 (Official Build) (64-bit)

Tried the same on newer everything, same result

Related to big inline string like the app CID in the footer

Describe the bug
Filsnap does not connect to MetaMask when multiple wallet browser extensions are installed. This seems to be due to the snap communicating with the wrong provider on the window.ethereum object. Might be related to missing support for EIP-6963, could help to look at the mpid package for identifying the right provider.

To Reproduce

1. Install other wallet browser extension next to MetaMask (e.g. Rainbow, OKX Wallet)
2. Try to connect FilSnap to MetaMask
3. Connection fails with the error that MetaMask does not support snaps
4. Disable the other browerser extensions and connect again, it works

Expected behavior
FilSnap should connect to MetaMask even when multiple wallet providers are installed.

• add input validation
• remove config options (derivation path, RPC endpoint, units)
• consider MM input around snap state sandboxing

• add more input validation
• avoid text snap ui element in favor of code blocks

Is your feature request related to a problem? Please describe.
Since updating to filsnap-adapter version 1.0.0 and using the official Metamask instead of Flask, we're subject to a lot more approval dialogs in Metamask. Basically when we call const snap = FilsnapAdapter.connect(...) and for every subsequent snap.configure(...) call, Metamask pops up a dialog to approve the requested path:

With Metamask Flask, it seems like the approval was cached so that the user only need to do it once.

Describe the solution you'd like
Ideally, approvals should be cached in Metamask so that the user doesn't need to re-approve.

Describe alternatives you've considered
After connecting the adapter, we need to configure the snap to derive the address for each account in the user's wallet. We consider caching those derivations in local storage instead of deriving them with the adapter, but it's still not ideal for the user having to approve the same information for each FilsnapAdapter.connect(...), or when switching accounts to sign transactions.

Is your feature request related to a problem? Please describe.

The front-end is currently hosted via HTTP and IPNS/DNSlink at a Fission.com domain.

Once #189 is fixed, it should move to a new domain that's specific to the app, not a specific company.

Describe the solution you'd like

• decide on a domain name
• register it, managed by Filecoin Foundation
• point domain to URL from #189

Describe alternatives you've considered

We tried domains of the companies who were leading development at the time, but that changes.

Maybe we can add a short description and link, from the docs:

The FilFowarder is a smart contract that lets users transfer FIL from an Ethereum-based f4 address to a Filecoin address of a different type.

Describe the bug

Run pnpm run docs

> root@ docs /home/runner/work/filsnap/filsnap
> typedoc --out docs --plugin typedoc-plugin-missing-exports --plugin typedoc-plugin-zod

[info] Loaded plugin typedoc-plugin-missing-exports
[info] Loaded plugin typedoc-plugin-zod
[error] Project at ./packages/snap has entryPointStrategy set to packages, but nested packages are not supported.
[error] Project at ./packages/adapter has entryPointStrategy set to packages, but nested packages are not supported.
[error] Project at ./packages/adapter-react has entryPointStrategy set to packages, but nested packages are not supported.
[error] Failed to convert one or more packages, result will not be merged together.
[info] Merging converted projects
 ELIFECYCLE  Command failed with exit code 3.
Error: Process completed with exit code 1.

To Reproduce
Steps to reproduce the behavior:

Make a release

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

Display the user account used for signing and the origin domain of the RPC call during the signing dialog, ensuring users have full context before confirming any transactions.

Describe the bug

After canceling sign-in in MM, app should handle and reset to initial state.

To Reproduce
Steps to reproduce the behavior:

1. Open fil snap page
2. Click on 'connect'
3. Wait for MM connection panel to load
4. See that you're on testnet
5. Click 'cancel'

Expected behavior

The app returns to initial state, with 'connect' button visible and ready to go.

Actual behavior

The app shows some funkily-laid-out error text where the 'connect' button should be.

Screenshot:

Tasks

Developer tooling and experience improvements

• Move repo to some PL Org
• Create a new npm package with PL bot
• Setup CI to publish with PL bot
• Change repo tooling to something more up to date and canonical for easier development and contributions
• Make sure all npm scripts and local dev is fully functional, documented and easy to use.
• Update dependencies specially from metamask and filecoin.
• Move tests from https://github.com/hugomrdias/filsnap-testing to the filsnap repo
• Move CI from https://github.com/hugomrdias/filsnap-testing to the filsnap repo
• Added notice about repo the new repo on https://github.com/ChainSafe/filsnap

Code Improvements

• Zod schemas with validations and types for RPC messages and metamask state
• RPC client for lotus using zod schemas
• onRpcRequest should check if fil_configure was called already and build up a "context" for other methods with snap, config, api client, keypair etc avoiding multiple instances and async tasks to get snap state.
• Remove dependency on @zondax/filecoin-signing-tools and Buffer
• Swap all the validation in src/utils/params.ts for zod schemas
• Check new snaps UI https://docs.metamask.io/snaps/reference/rpc-api/#snap_dialog and src/util/confirmation.ts
• Add pnpm patch to snaps-cli/dist/utils/misc.js changing config file to snap.config.cjs
• Write new RPC or use some other client like izari-filecoin
• compress snap bundle https://github.com/terser/terser
• flask now forces semver in the snap version option change metamask-testing-tools to account for that
• tests need to have the snap version injected from the snap manifest
• export private key MM popup needs rework
• sign raw popup rework
• send message popup rework

Metamask 10.28+ compatibility

• Research metamask new flask/snap permissions system (caveats based) and plan changes needed in filsnap.
• Update filsnap to the new permissions system
• Document changes and how it works to make future changes easier. (metamask said it may change again multiples until 10.29.0/end of the year)
• Unit and e2e tests for these changes.
• Check snap config type and check if we need to refactor it and where all the properties are used.
• Make sure the snap manifest gets updated and committed in the CI

Filsnap adapter

• Merge #6
• Make sure there are no breaking changes to the adapter API
• Rework the demo
• Publish demo
• Check filsnap icons for the install snap popup
• Publish new package to npm
• e2e tests running against the demo app
• Fix selection highlight in the demo app
• deploy with npm:filsnap SNAP_ID

Support FEVM transactions

• Research FVM/FEVM transactions, requirements, flows and tools.
• Support send FIL to f410 addrs
• Handle FEVM transactions (cbor encoded)
• New unit and e2e tests for FEVM features
• Update demo page with FEVM features
• Collaborate with Glif to validate filsnap works as expected

Others

• Write up about moving aways from zondax dependencies
• Improve packages readme and add a few examples
• Improve js docs descriptions
• #35 (not possible)
• #36
• #37
• #38

References

• https://github.com/ChainSafe/dappeteer#usage-with-snaps
• https://github.com/MetaMask/snaps-monorepo
• https://www.npmjs.com/package/@metamask/snaps-cli
• https://docs.metamask.io/guide/snaps.html
• https://github.com/ChainSafe/filsnap
• Original issue ChainSafe/filsnap#132
• https://hyperspace.yoga/#faucet
• https://faucet.calibration.fildev.network/
• https://github.com/Zondax/izari-filecoin
• https://github.com/glifio/modules

Notes

• Glif RPC nodes docs https://api.node.glif.io/

playwright is creating trace zips in the test-results folder and not playwright-reports

We want to support sending FIL/tFIL from f1 addresses to 0x/f410 addresses in the snap for better FEVM support as requested in #8.

The demo already has a transfer form, but the recipient field only accepts f1 addresses:

We could change this to accept 0x/f410 addresses as well in the recipient field, similar to how Glif burner wallets work:

As far as I can tell, this would need the changes listed below.

Demo

• Convert 0x addresses to f410 addresses in the demo app for the transaction's to field before calling the snap RPC.¹
• Update the UI.

Snap

• Support signing a message where the to field is an f410 address.²

This is on local dev, master at f0a8e4c