Recently I wrote about our struggles to use
dat:// with react-native. As a follow-up, I would like to start this meta-thread for getting
dat:// to run smoothly on/with React-native.
→ If you are interesting in supporting and/or collaborating this please comment and share your struggles or success stories!
I believe that there are a few teams here that try to get dat:// to run on mobile devices and together we should be able to make this a lot easier.
↓ Geeky & detailed problem description follows below ↓
Thinking about what could be done, basically we have identified two different aims:
dat://to run in a regular react-native environment
These are fundamentally different aims as
expo does not support native extensions beyond those bundled with the expo test app. This means…
- tcp sockets do not work. (you can & should vote for adding it
- we can not use nodejs modules, which is can be worked around using the nodejs-react-native extension but that is not part of expo.
- it will not be possible to run cryptography natively. The react-native-communication does not support ArrayBuffers (vote →
react#arraybuffer-over-rn-bridge) and requires to be asynchronous, using Promises. Even if we could prevent multiple allocation of the memory and the resulting performance loss when operating with the native API, we would still need to make all crypto calls inside dat asynchronous, as the libsodium api is synchronous (lots of changes with problematic performance impact on other platforms).
The impact of this is that for expo and the foreseeable future, we need to use WebSockets or maybe
expo#webrtc (please vote for this) to connect to the
dat:// network. Also, either all packages need to be adjusted to work within the limitations of the expo build system (e.g. use the
buffer npm package or a working version of ReactNativify-setup needs to be prepared to run dat out of the box.
For both approaches we have identified these first general issues (please comment if you find others):
- Writing to the filesystem on mobile devices can be a bottleneck. Aside from hardware limits, the expo file API is very rudimentary and getting a well-performance
random-access-*system working might be a challenge.
- If you have special network settings, those need to be set for every mobile app. It would be good to have standard settings that could be set-up once and work for every mobile app (the same way).
- Displaying and controlling media assets in mobile phones is (much more than on desktop) working through threads. Using the
react-native-nodejsmessage API, the image/movie assets need to be sent using strings which will be passed between two threads. String/Buffer transformations are heavy which will certainly make image display not quick. This is exasperated to the issue that
react-native-fast-imageis not added to expo (vote for it → expo#add-react-native-fast-image).
- Dealing with the app running in background is very tricky. Should the connection be dropped? Should it be kept alive for a little and dropped after a while? It would be good to have best practices here.
- React-Native does not support WASM/Webassembly (vote →
react-native#support-wasmwebassembly), which means modules in the
dat://ecosystem would need to continue to work without using wasm. There are workarounds using Webassembly.js, but they bring problems: further reading: