feat: Adding Meteor Wallet to the project

[lostpebble]

Description

This adds Meteor Wallet to the Wallet Selector project. I've used the other modules as a template and added Meteor configuration in all the relevant places.

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation (examples)
• My changes generate no new warnings

Type of change

• FEATURE - a PR of this type introduces a new feature.

Breaking changes

• NO BREAKING CHANGE - this PR doesn't contain any breaking changes and it's backwards compatible

---

Documentation

I've you'd like more documentation on the Meteor SDK, you can find that here. It implements an interface very similar to Near Wallet, as seen inside near-api-js.

Small Issues during integration

EDIT: Solved with next commit (adding @meteorwallet/sdk into the root package.json - following what nightly-connect has done)

• Running yarn at the root does not install @meteorwallet/sdk into packages/meteor-wallet
  • We need to run yarn inside the package folder
• Running examples work with Meteor Wallet, only if we delete the version of near-api-js inside packages/meteor-wallet/node_modules that was installed by @meteorwallet/sdk - forcing the SDK to look higher in the tree and use the same node-api-js used in other parts of the wallet selector.
  • This is a problem with borsh serialization and duplicate packages, where the classes have to be exactly the same classes pulled from exactly the same module during serialization and transaction creation. This should not be an issue in a real-world scenario where dependencies are de-duped at the project level correctly.

An example of what the error message looks like:

---

The wallet is live and ready for you guys to test this integration out :)

[kujtimprenkuSQA]

Hi @lostpebble thanks for submitting this PR.

Can you please change the base form main to dev branch?

Can you also update the main Readme file to include meteor-wallet too?

For the near-api-js errors regarding Class Action, have you tried to match the versions?
Like using the same version of near-api-js in your project to match with the version we have in this repo?

[lostpebble]

Thanks for the review @kujtimprenkuSQA !

I think I've covered all those bases- and changed to the dev branch for the PR. Please let me know if there's anything else :)

[kujtimprenkuSQA]

Hey this looks good, it's just that when you changed the base from main to dev there are some conflicts since we made some updates in dev branch last week.

If you have any difficulties with this let me know.

Also when the window opens to connect Meteor Wallet even though I am trying to connect from localhost it shows this site:
https://meteor-guestbook-example.pages.dev/

[lostpebble]

Also when the window opens to connect Meteor Wallet even though I am trying to connect from localhost it shows this site:
https://meteor-guestbook-example.pages.dev/

Ah shucks, that's a debugging thing that I hard-coded and forgot to remove. I'll change that now to function as expected. Thanks for pointing it out!

Hey this looks good, it's just that when you changed the base from main to dev there are some conflicts since we made some updates in dev branch last week.

If you have any difficulties with this let me know.

Cool, will look into merging that now.

[lewis-sqa]

Few comments from me 👍

Disclaimer: This was purely a code review - I've not yet pulled the repo down and tested it so apologies if some of my comments are irrelevant!

[lewis-sqa]

I seem to be hitting the following error when building the repo:

SyntaxError: Unexpected token 'export'

Along with this error:

Uncaught at /Users/lewis/development/meteor-wallet-selector/node_modules/ (meteorwallet/sdk/dist/meteor-sdk/src/index.js:1)
    at Object.compileFunction (node:vm:352:18)
    at wrapSafe (node:internal/modules/cjs/loader:1031:15)
    at Module._compile (node:internal/modules/cjs/loader:1065:27)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.@meteorwallet/sdk (file:///Users/lewis/development/meteor-wallet-selector/dist/examples/react/.next/server/pages/index.js:664:18)
    at __webpack_require__ (file:///Users/lewis/development/meteor-wallet-selector/dist/examples/react/.next/server/webpack-runtime.js:33:42)

[lostpebble]

Hi @lewis-sqa , thanks for much for the review so far!

I seem to be hitting the following error when building the repo:

SyntaxError: Unexpected token 'export'

Yea, I noticed this error popping up now after rebasing our branch onto dev . It seems like the React example is built differently now, perhaps using Next?

I'm in the process of trying to solve this, nothing has changed on our side- or perhaps while I was rebasing I missed something.

[lostpebble]

I've found the "export" issue: vercel/next.js#31518

Turns out Next.js doesn't automatically convert ES Modules, like Webpack and other do.

And when I change the package.json of our SDK to have:

 "type": "module",

Now I get this error:

Error [ERR_REQUIRE_ESM]: require() of ES Module F:\dev\projects\github\wallet-selector\node_modules\@meteorwallet\sdk\dist\meteor-sdk\src\index.js from F:\dev\projects\github\wallet-selector\di
st\examples\react\.next\server\pages\index.js not supported.
Instead change the require of F:\dev\projects\github\wallet-selector\node_modules\@meteorwallet\sdk\dist\meteor-sdk\src\index.js in F:\dev\projects\github\wallet-selector\dist\examples\react\.next\serv
er\pages\index.js to a dynamic import() which is available in all CommonJS modules.

Seems the SDK is not getting pre-bundled with the other code, and the code is using require() to import the SDK, which is now failing. This is another of those wonderful JavaScript conundrums which I've been battling with for a while... The ecosystem changing over to ES Modules and breaking compatibility.

[lostpebble]

I think I'll need to re-compile our SDK to commonjs for it to work.

[lostpebble]

I changed our module and now I'm getting this error:

ReferenceError: window is not defined

This error happened while generating the page. Any console logs will be displayed in the terminal window.

This is because of this code in our SDK:

const locallySetBaseUrl = window.localStorage.getItem("DEV__METEOR_WALLET_BASE_URL");

export const envConfig: IEnvConfig = {
  wallet_base_url: locallySetBaseUrl ?? WALLET_URL_PRODUCTION_BASE,
};

This code is always expected to execute inside the browser... but thanks to Next.js this is now throwing an error. I've run into things like this before with them- very annoying since clearly we're building for browser but window is not allowed because it executes within a Node.js context.

[lewis-sqa]

const locallySetBaseUrl = window.localStorage.getItem("DEV__METEOR_WALLET_BASE_URL");

export const envConfig: IEnvConfig = {
  wallet_base_url: locallySetBaseUrl ?? WALLET_URL_PRODUCTION_BASE,
};

This code is always expected to execute inside the browser... but thanks to Next.js this is now throwing an error. I've run into things like this before with them- very annoying since clearly we're building for browser but window is not allowed because it executes within a Node.js context.

Might be worth adding a condition around Web related APIs to make this module somewhat isomorphic. We actually moved to Next.js recently to ensure Wallet Selector handles this correctly as SSR seems to have caused problems for people in the past

[lostpebble]

Might be worth adding a condition around Web related APIs to make this module somewhat isomorphic. We actually moved to Next.js recently to ensure Wallet Selector handles this correctly as SSR seems to have caused problems for people in the past

That's fair, better to error early. I've wrapped it with a check now.

[lostpebble]

I've made a lot of edits now. It should be working, as the examples worked for me. Just need to look at some small final things recommended by @lewis-sqa about signerId in Transactions, and the Sign In action.

[lostpebble]

@lewis-sqa @kujtimprenkuSQA I think I've finished adding all the requested changes and verified that its working with the example. Please check and let me know if everything is up to scratch :)

[lostpebble]

Shucks, always the small things that slip through! 😛 Cool, think I've changed the name in all the relevant places and removed that .gitignore file. Hopefully we're good to go now.

[lewis-sqa]

This looks great. Thanks for all your efforts @lostpebble! 🎉

[lostpebble]

Thanks so much for the reviews and helping to get this merged @lewis-sqa and @kujtimprenkuSQA ! Happy to be a part of the ecosystem :)

[lostpebble]

Is there any ETA on the next version release btw? So we can get our integrators to start testing it out

[janewang]

@lostpebble Thanks the PR, we are planning Wallet-Selector 5.1.0 on Tuesday, August 16. We are planning to add this PR and enable Meteor Wallet. Cheers

[lostpebble]

Hi @janewang - for a minor addition like this, this seems like a very long release schedule. I also see a minor version was released in-between without our new changes.

We are trying to iterate fast, and for this we need our integrators to start using Wallet Selector so they can test out Meteor on their dapps. This PR was merged 19 days ago now- yet there is still seemingly 15 days to go until the decided release date (more than a month total to get a version with our wallet included)... Could this also have something to do with the big official change over to MyNearWallet (I read something about a big release announcement on the 17th of August)?

This is a big blocker for us, as we've pushed for Wallet Selector to be our main integration with our users. For us to take our next beta steps we really need this functionality to be live now. Please could you consider another minor version that includes our current changes?

[janewang]

Hey @lostpebble There is definitely significant resources devoted to various initiatives. We are looking to make sure the releases we announce can go out in time. Unfortunately the team working on wallet-selector is quite short handed esp given August vacations and natural attrition. Will discuss internally on what we can do.

[lostpebble]

Thanks @janewang - appreciate the work of everyone involved!

[janewang]

@lostpebble

Please kindly confirm that the follow criteria are met or can be met within the required timeline. Thank you.

Criteria for Including New Wallets for Wallet Selector

Product Criteria:

A wallet project must have comply the following product criteria to listed on Wallet Selector.

• Non-custodial: The user controls their funds.
• Conformity to Wallet standards: The wallet product conforms to NEAR NEP wallet standards (Injected Wallet Injected Wallet Standard NEPs#370 and Bridged Wallet NEP-368: Bridge Wallet Standard NEPs#368)
• Ease of use: The wallet product provides a usable interface for the end user. Please provide a user guide for review.
• Ability to recover accounts: The wallet product allows users to be able to recover accounts.
• Actively maintained: The wallet is actively maintained by a team and can answer user queries.

Security Criteria:

A wallet project must have the majority of these security program features in place with self-certification that remaining items will be in place within 6 months of being listed.

Wallets shall checkbox a statement of compliance to be maintained on the wallet’s github account. When asserting that open items will be in place within six months of being listed, target dates shall be included. The overall statement must be dates and the date shall be commensurate with the commit date. All wallet projects must maintain compliance. If a wallet is no longer in compliance, or no longer supported, the security statement must reflect that change. The wallet project shall make verification of the following requirements as easy as possible maximizing transparency through the use of relevant links pointing toward program descriptions, audit reports, etc. for the user/researcher.

• Has a security program in place that covers or is dedicated to the wallet
• Publishes information about its security program in an easily findable place
• Conducts regular audits of wallet code, at regular intervals of less than a year or based on meaningful code changes
• Conducts regular penetration tests, both “authenticated” and “non-authenticated” upon significant code changes
• Conducts penetration tests on related infrastructure, such as databases, virtual machines, web servers, etc.
• Remediates any critical, high, or medium findings from audits (3, 4, an 5 above) and tests in a rapid fashion, as suggested by auditors and penetration testers–with auditors validating the remediation in their reports.
• Makes such reports (audits, penetration tests) publicly available, on at least a summary level
• When making reports (7) available, wallet projects should ensure the equivalent reports appear on the security vendor’s site or simply links to the security vendor’s report. This ensures the authenticity of the audit reports.
• Conducts operational readiness reviews and testing or an equivalent process before deployment to production to ensure that code changes have not resulted in unanticipated behavior, compatibility issues, or in
• Maintains a testnet wallet
• Maintains a bug bounty program
• Implements minimal privilege and access policies with regard to supporting infrastructure
• Implements MFA and strong passwords for access to critical related systems, such as domain registration, hosting platforms, cloud platforms, etc.
• Conducts known vulnerability and vulnerable dependency checks; and remediates critical, medium, and high findings before bringing into testnet or production.
• If the wallet is a browser “extension,” it is listed on the official extension marketplace

[lostpebble]

Thanks for the criteria update @janewang. I've created a public repo (https://github.com/Meteor-Wallet/meteor-public) where we will put all the required documentation and things, and let you know once we're ready. We'll also be updating the wallet according to the "Injected Wallet Standard"- although I did have a few concerns about the API there which I have mentioned on the specific PR for that document ( near/NEPs#370 )- it seems that it is deviating from the API given in the current version of the Wallet Selector repo.

We really need to get merged as soon as possible because not being on Wallet Selector is putting us in a tough spot with integrators- who we've been pushing "wallet selector" on as our main integration. I hope that we will be up to standard for the next release- we're a little disappointed that this criteria only landed right now, but I'm guessing this is a new process on your side that has only just been wrapped up.

[lostpebble]

@janewang @lewis-sqa we will be implementing our new changes in accordance with the current Wallet Selector interfaces- using our internal SDK to communicate with our extension and website (depending on context, mobile, desktop etc.). As all wallets in the wallet selector currently implement those interfaces, we hope that will be fine to allow us to be integrated in the next version.

[janewang]

@lostpebble Great to hear that you are planning to update to the wallet standards for product and security. We are planning to list meteor wallet in the upcoming release next week.