Native integration next

[gnunicorn]

This moves the rust part into a separate package in packages/zoe_native for a cleaner separation of concerns. In that new package this

• was updated to the latest relay client from the rust repository
• adds the ability to create a relay-client and connect to the dev server at startup
• stores the secret of the relay-client securely and restore from that state
• has the riverpod providers moved over for live data handling, uses the userId providers as a first implementation

Look, the user id is directly derived from the natively provided internal encryption keypair \o/ .

The new integration platform (flutter rust bridge) we are using has several advantages, which is why we want to use that as closely as possible. In particular it allows for direct mapping of the rust types into dart types in a static typed manner - neat! As a result most models will directly be managed and provided by the package and so will the the riverpod providers. One reason we can allow for that is the API allows for being mocked as well, so we can still do all the nice and fancy testing with nice mocking while also being sure that the types match statically - how awesome is that?!?

---

So, there was a few bugs in actually connecting to the server(s). Since I first wrote this a few updates have happened that are now included:

• the clients work offline, meaning it starts fast and only connects after and syncs up, you can already start using it (you see the icon on the top right changing state) -- properly provided through the riverpod providers
• tests for the riverpod providers and general smoke testing of the plugin to ensure it isn't dying due to static linking failures.
• we've switched to using the secure storage rather than the preferences to store the session keys securely
• due to some internal bugs I needed to debug, there is now a new developer tools section in the menu (see video cast below), which allows us to:
  • 1. run a full systems check, with live updates, ensuring the app features work end-to-end over the target server and report any issues if it encounters them (the idea is to extend this with further tests as we go along)
  • 2. allows you to reset the session keys stored locally, to start a fresh session.
• we are now reusing the same CI builder helpers from the main zoe-relay-repo so we are always in-line with the requirements added there for building the native

See it in action:

systems-check-in-zoe.mp4

[kumarpalsinh25]

@gnunicorn
Is this PR is ready for review or still under development?

[gnunicorn]

I left it in draft, as the server isn't reliably up yet and the client would stop functioning/block right now. So I first want to tackle the offline-ability and then maybe go towards merging...

[gnunicorn]

@kumarpalsinh25 okay, we now have an offline aware client and I think that means we can merge this in and start playing with the actual native interface ...

[kumarpalsinh25]

Many of the code I don't understand but I tried to review flutter or we can say dart code. Everything looks fine to me in general.

[kumarpalsinh25]

Do we need to submit generated files to git?

[gnunicorn]

I am not 100% sure about that, but I think that's the idea of the tool, because otherwise you'd have to run a manual CLI after every checkout, and all other things are directly included to be run