Specification

We want PK to be truly cross-platform. But PK is very complex, involving many components are not truly cross-platform. These components include:

• Crypto code - this code often relies on native code to generate random numbers, to be performant and to be secure
• Networking - this code often relies on native or platform-specific network functionality
• Database - this code often relies on native or platform-specific filesystem behaviour
• IPC Locking - this code often relies on operating system POSIX features
• JS runtime - the runtime itself is platform-specific as it needs to run our javascript
• GUI - this code is often platform-specific due to the GUI chrome and components

Over the development process of PK, we've found many roadblocks to achieve a truly cross-platform PK system. This issue tracks all of these areas, and the progress towards more cross-platform deployment necessitating multiple new solutions in multiple areas.

• crypto - webcrypto or WASM can help
  • webcrypto provides a common foundation
  • wasm can provide additional crypto utilities that isn't part of webcrypto
• networking - using http3/quic may help
  • quic & http3 is the most likely future standard
  • different platforms may require native access to use
• database - indexed db, this may still require native code no matter what
  • leveldb - C/C++ codebase
  • rocksdb - more advanced than leveldb, can help implement block-level encryption
• ipc locking - this may still require native code no matter what because platforms define their own understanding of what inter-process means
• js runtime - understanding v8 can help because v8 is embeddable and jitless mode works on ios
  • deno is still very green, but it's interesting, it has v8, but will not support nodejs native addons
  • nodejs itself is embeddable, and uses v8
  • jitless v8 works on ios
• GUI - GUI is likely to be platform-specific no matter what, a number of solutions can bridge some platforms however, focusing on HTML/CSS standards should help
  • electron - for desktops only, results in huge packages
  • tauri - rust backend, much smaller packages (10 MiB vs 100 MiB), but can bundle nodejs https://tauri.studio/guides/building/sidecar/
  • nativescript - does not have all web standards available, may need to use native code or WASM - https://docs.nativescript.org/native-api-access.html
  • sciter - not open source
  • godot - game engine (completely different model https://medium.com/swlh/what-makes-godot-engine-great-for-advance-gui-applications-b1cfb941df3b)

This issue is likely to be a moving target, since cross platform development solutions keeps evolving.

Additional context

• Migrating/Integrating WebCrypto (possibly WASM) instead of Node Forge Crypto #270 - exploring webcrypto and wasm for crypto
• Transport Agnostic RPC #249 - RPC behaviour, moving towards json-rpc plus HTTP2/HTTP3 might be a better idea
• GRPC Web Proxy to enable Browser Integration and Eliminate Electron IPC #235 - grpc web proxy may not be necessary if we move away from GRPC
• Using QUIC/HTTP3 to replace utp-native for the Data Transfer Layer in the networking domain #234 - quic/http3 over utp-native
• Third Party Integration - HTTP API, OAuth2 Provider API, Plugin API, Library vs Framework, Smart Tokens #166 - third party integration should be easier with json-rpc than with grpc
• React Native and Mobile OS (iOS and Android) Compatibility #155 - mobile/nativescript compatibility

Tasks

1. ...
2. ...
3. ...