1Wallet Features

1Wallet Features

Next Date
January 1, 2022
Assign
Aaron LiGiv Parvaneh
Status
Live on Mainnet
Github
Bounty
Grant-1
Grant-2
Grant-3
Release Date
💡
Giv: Moving this to completed since the scope is too broad. We’ll create smaller, specific tasks.
  1. Support WalletConnect, and add to the Registry.
  • Multisig + Walletconnect+Mobile wallets on Polygon/Arbitrum - Dharma, imToken
  • The user should save 1wallet to home screen. When they do, the data will be retained indefinitely. Otherwise, Safari mobile will automatically wipe the storage if the user uses Safari mobile for 7 days without ever interacting with 1wallet. See primarily https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ “7-Day Cap on All Script-Writeable Storage” and “A Note On Web Applications Added to the Home Screen” See also similar concern raised in nearwallet but left unresolved https://github.com/near/near-wallet/issues/479. See also discussions in https://news.ycombinator.com/item?id=22686602
  • The multisigs should all have signatories other than 1wallets as alternatives. By the current design, 1wallets will expire in 12 months, so are their upgrades. There are design proposals to let wallets self-extend its expiry date. The design is straightforward but is not implemented or tested. It works retroactively for this specific multisig use case, in the sense that when the design is implemented, the wallet can be upgraded, and the upgraded wallet can extend its own expiry date. Even though the upgraded cannot extend its predecessors’ expiry date, it [the latest upgraded version contract] is authorized by its predecessory to call arbitrary functions, including calling [authorizing] multisig wallet to do something
  • Aaron Li’s review:
  • I built the iOS version and tried on simulators. The main issue is it requires too much efforts to set up. To users, it looks like an app on homescreen. It is recognized as a Safari extension under Settings -> Safari -> Extension. There it has to be manually enabled for Safari, and set to “allowed” on all websites. The demo page would not function unless the user has completed this configuration. It appears the web page itself cannot request the user via Safari to grant the requested permissions or to allow for specific website. The demo also has issues sending information back to the webpage itself.

    I spent a lot of time fixing bugs and messing with dependencies and version compatibilities but still can’t get it built for macOS.

    Overall, at this stage, it does not seem to offer anything an app could not offer, nor any superior user experience. Later it could be something that universally bridges mobile web dApps with mobile wallet apps, so dApp developers won’t need to integrate and test mobile walelts one by one.

    Another issue with this project is the whole thing is written in Swift, thus cannot easily utilize the vast number of web3 libraries out there in javascript. Rather than building a Safari extension, I think a smarter way to build a react native app on iOS that could also act as a Safari extension, thus making good use of both existing code base, the existing javascript libraries out there, and also take advantage of the extension framework once the user experience gets better over the next 1-2 iOS versions. A react native app can also natively run on macOS arm64