iOS Support about covid-19-recovery-identification HOT 5 OPEN

I was able to add IPv8 to the custom Python interpreter and now the service works. As of now the size of the whole application including the Python interpreter is around 40MB and in terms of RAM - 50MB. There are some optimization which are still missing that will potentially shrink the whole package even more. I am yet to compare the performance of this implementation to other available solutions.
NOTE: The size will probably grow when the service becomes part of an Android or iOS application!

from covid-19-recovery-identification.

At last! I got IPv8 to work inside an APK. I was able to turn the whole service with all its dependencies into a single file that is later used by Android as a library to initialize IPv8. The only dependency that is being loaded dynamically and I cannot include inside this master file for now is libsodium. It is provided separately to the APK.

I have not done many performance tests, but in debug mode, the APK is 13MB and uses around 35MB of RAM. I will have to do some more testing to include battery usage and make my findings conclusive. Also the library still contains debug symbols and other junk that when removed should decrease the footprint further.

The version of Python that IPv8 is using is 3.8.7 and IPv8 itself is 2.5.0, but it should work with the newer version as well. The minimum SDK requirement that I have tested for is 21 which covers around 95% of all Android users globally. Also all IPv8 dependencies are up to date.

I was able to run the whole test suite for IPv8 and out of all 544 tests:

one causes a lock up:
ipv8.test.messaging.anonymization.test_community: test_tunnel_data

and 9 fail:
ipv8.test.messaging.interfaces.dispatcher.test_endpoint: test_is_open

ipv8.test.test_configuration: test_set_illegal_walk_interval, test_set_illegal_log_level, test_illegal_random_churn_strategy, test_illegal_periodic_similarity_strategy, test_add_key_illegal_curve, test_add_illegal_port_big, test_add_illegal_address, test_add_illegal_port_negative

All other tests pass and the output is identical to the one observed when I ran the tests on Linux. There were no changes made to IPv8 to address the failing tests. The only change I have made was to remove the docs, since they increase the size of the application by 10MB. I haven't yet tested IPv8 manually with two instance communicating with each other but 'stdout' gives me confidence that the service is performing properly since it establishes connection with the Communities from the default configuration.

The next step is to implement a solution for iOS, because it makes for 40%+ of the mobile devices in the Netherlands. I assume that getting the support for iOS should be a matter of changing some environmental variables because of the way the tool builds the standalone version of IPv8.

Regarding the tool itself, it is still under development but at some point I plan on releasing it as an open source project on GitHub. It just needs to be a bit more mature so that other developers can make use of it.

I will soon add some more material to this issue that will showcase the progress made.

from covid-19-recovery-identification.

I have diverged from using an already developed tool for running the IPv8 service on iOS and Android. The service works well with Chaquopy, but has issues with Beeware's and Kivy's implementations. Unfortunately, Chaquopy is not available for iOS and is not open source. That makes it a poor choice for this project.

Since there are not any better solutions for now, I decided to build my own tool. I was able to compile a Python version for Android that is using only 16MB for the whole interpreter with all libraries which Python depends on. It also uses around 20~25MB of RAM. That is a tremendous improvement over the already mentioned solutions.

The tool is still in a proof of concept stage and does not have automatic build scripts which prevents running arbitrary Python projects on demand. Also, Python itself is packaged as a binary executable and executables are not allowed in Android at least.

The next stage will be to add the necessary automation and turn the executable into a library which can be referred to by iOS and Android through a bridge. This might possibly further reduce the size of the interpreter. Also there are a couple of modules which were stripped out but can be added if needed. Those are test, tkinter, setuptools, pip, lzma.

from covid-19-recovery-identification.

from covid-19-recovery-identification.

@kkostadinov99 very impressive work!
We did a test with native implementation of Trustchain and a digital Euro last week. The native Android implementation in Kotlin is slowly getting mature. Not feature complete and not as mature as Python, but getting there. Apologies for not sharing this earlier, but please consider switching to this branch for future development or projects.

the APK is 13MB and uses around 35MB of RAM

Very small and efficient. Using the Java interpreter or the Python virtual machine is closer then I intuitively thought.

from covid-19-recovery-identification.