Architecture for the native app using react-native.

[burtonator]

Overview

We need to have a mobile app to help resolve issues with our app on mobile devices.

The main benefits would be:

• the keyboard would work properly on mobile
• the push notifications would work with FCM and have an icon associated with them (we don't have an icon now on mobile browsers)
• we would get app distribution through the app stores
• any future native features would be easy to implement rather than fighting with mobile browser

Design

• use react-native to build the app. The project size is super small. It's probably going to be < 1000 lines of code. It's mostly just glue around a Webview (browser) control
• Use the Expo Application Services CLI to push to the cloud then into the app store. The idea is that eas builds the app, pushes it to the Expo cloud, then we can submit them to the app stores from with CI/CD
• The mobile app needs to load the production site, then store the code in the browser cache so it's available to load when offline.

The first step is to make sure the webserver and everything can work properly together.

Issues

Loading the app via remote URL

In the past I've used an embedded web server to load the application code. However, that project is not 4 years old and I cant' find a modern implementation.

It also DOES NOT support SSL/TLS so we can't go that route.

We would have to load the production URL (common.xyz or commonwealth.im) via https in the webview.

We will have to make the following changes:

• We have to implement deep linking so that any URL loaded in the browser loads in the mobile app.
• We have to use the cache API so make our PWA available offline. If we don't do this the webview would give an error that it can't load our site if the device is offline - possibly breaking our app. I think we should not do this in the initial version. We should use workbox to do this as this is the easiest route but it's still somewhat difficult. We really only need to cache the static assets. The main issue is what happens the FIRST time the app loads. They need to run it at least once to get a cache of the app assets.
• provide a way to get the app version from the server to determine if they're compatible.

Auth

TODO: I think this is going to require the more research. It seems like Metamask runs an embedded browser and then provides window.ethereum. Of we run within our own react-native app we won't have window.ethereum so I do not think any of our crypto APIs would work. Apparently, there IS a way to make it work with the native browser but we're going to have to make 100% certain that this would work. This is probably the trickiest issue we're going to have.

For auth I think we should use a combination of browser auth and redirecting to the mobile app with a token to grant auth inside the mobile app.

We should NOT do the full auth flow inside react-native.

There's also the benefit that the browser has existing credentials so it would prevent them from entering in their password again.

We'd have to exclude auth.commonwealth.im from direct linking so that it loads the browser, then redirects BACK into the app with an auth token.

The auth token would NOT be the JWT token ideally. We should not be exposing this as we are now but should just serve it as an HTTP cookie. We would have to have a mapping from the auth token to the JWT token so that auth doesn't happen on the backend again.

I wold need to think about this more because if the auth token leaks, there's still a security issue because that could be used to get the JWT too. We'd have to write this up in greater detail and also try to figure out if there's an 'official' way to do this that's more secure and documented.

Apple/Google Approval Issues.

Apple generally requires you to have a valid reason to ship a mobile app.

I think our reasoning is that:

• the keyboard needs to work
• we use native OS push notifications

I think that's enough to get approved.

The main issue I see is that Apple does not allow you to load remote code. All your code needs to be served from the device and they might view loading our app from the website as bypassing that.

We could do some more research (maybe ask on reddit) to see if we're ok with this strategy.

Tasks towards implementation

• re-init our existing react-native project. I created it 8 months ago and I think it's missing some dependencies but all the code should build.
• get the build to work with Expo Application Services
• The initial version should just load the app via our website inside a react-native Webview control.

Issues

• react-native-static-server is VERY old and does not support https... It looks like it uses native modules for iOS and Android so I do not think it's going to be as easy as just adding support for https. The module is also four years old and no longer maintained.

[dillchen]

On auth, it’s not “necessary”. On mobile, users are not show any injected wallet options (I.e uses window object), instead we only show wallet connect. This is standard across other web3 mobile apps.

Wallet connect has their own deep linking protocol and links to other mobile wallets.

I would really not worry about this.

See an app like Drakula for example: https://apps.apple.com/us/app/drakula-watch-videos/id6476138397