Displaying link to metamask page on install #7
Conversation
dafuga
force-pushed
the
displaying-link-to-metamask-page
branch
from
757b571
to
7ffd33d
Compare
packages/snap/src/index.ts
Outdated
| } from '@metamask/snaps-sdk'; | ||
|
|
||
| import { getPublicKey, signTransaction } from './rpc'; | ||
| import { AntelopeRequest, AntelopeSignatureRequest } from './types'; | ||
|
|
||
| const SNAP_NAME = 'Antelope MetaMask'; |
There was a problem hiding this comment.
This needs to be "EOS Wallet" I believe.
While the plugin itself is generally Antelope-compatible, the release I think we will do is EOS-focused, and to line up with the other Snaps, we can just call them "CHAIN Wallet".
I'm not sure if there are other places in the app that call it an "Antelope" product, but if there are - if we could make them all reference this variable (to easily rename the release), that'd be awesome
There was a problem hiding this comment.
Renamed the snap 👍 The other place where Antelope is used is in the package name which is currently @greymass/antelope-snap. I guess that should be @greymass/eos-snap as we'll probably need a different repo for each chain? 🤔
There was a problem hiding this comment.
Yeah, makes sense. I renamed the repo to:
https://github.com/greymass/eos-wallet-snap
Yeah we may need a repo for each chain. Unsure of what the best structure is. We could:
- Clone this codebase a number of times, once for each chain
- Use branches on this repo, one branch for each chain
- Setup one core Antelope repo, and then make a fork for each chain
That last option could be the best? It would let us pull changes from upstream (the Antelope repo) into each chain repo, as changes become available.
There was a problem hiding this comment.
Yeah, I agree that using branches may be the easiest. If we go that route then should we rename the repo to @greymass/antelope-snap?
There was a problem hiding this comment.
The one argument I can think of for using forks instead of branches would be more fine grained permissions, like if we wanted to be able to allow specific collaborators from specific chains.
Another argument might be around CI/CD, if we want to go that route 🤔
There was a problem hiding this comment.
The advantage of going the branch route is that we won't have to worry about having to explain why we have different packages to the consensys folks.
They have to be different packages no matter what we do. Did you mean different repositories?
It also might be just as confusing to them to have one repo with different branches 😓
There was a problem hiding this comment.
Yeah sorry, I meant repositories. I think that sticking with the single repository that was already audited will be simpler than trying to submit a fork of a repository that was audited.
There was a problem hiding this comment.
I guess I'm not against submitting a fork and seeing if it works though. I could be overthinking this 😅
There was a problem hiding this comment.
In any case, we agree that we should rename this repo to greymass/antelope-snap? From there, we could either create a new branch or fork for each new network wallet.
There was a problem hiding this comment.
Yeah, I'll rename it back to what it was - and we can create a branch.
The audit also specifically says greymass/antelope-snap, and even renaming it might cause some confusion.
The package we release however should be named eos-wallet (or similar) when we publish to NPM/etc.
No description provided.