Question about Lamp update and lightningd updates

[darosior]

Would Lamp check if I'm not running the latest lightningd binaries ? And if so would it be downloading them on startup ?

[lvaccaro]

Now, Lamp fetches binaries from https://github.com/lvaccaro/lightning_ndk release artifacts and the tag name is hardcoded in the app.

Unfortunately, lightning_ndk releases could not strictly match lightningd release: we could require to update esplora plugin or something else, or we don't provide tag version for minor releases. So I think the version check should be on the lightning_ndk repo and, in that case, the app need to get the installed lightning_ndk version.

[darosior]

Yeah, I meant: would be great that Lamp detect at startup that a new Android-ported lightningd binary is available at https://github.com/lvaccaro/lightning_ndk

[lvaccaro]

Yes, and also the app should know the installed lightning_ndk version to compare with it. Have you any suggestions?

[lvaccaro]

I am thinking to remove the download functionality from the app and embed clightning binaries in the apk.
So a user with the last version of the app has also the latest version of clightning and esplora.

On the other hand, this force update of the clightning binaries allows to be aligned with the daemon booting procedure: clightning options parameters could be updated based on lightning version, so a Lamp release (with new interface) could be crash running an older clightning binaries (it requires to manually erase binaries and redownload again).

What do you think?

[darosior]

it requires to manually erase binaries

Why manually ?

What do you think?

This seems wise with regard to Lamp <--> CL compatibility. However my main interrogations are on the Android side: will i be able to update as today with "this won't erase any data" message ? I like this, and i think potential less technical users will really rely on it in the future. If binaries get replaced maybe it won't appear (or worse "this will erase old data") ?
Also, would it keep the APK size reasonable ? Maybe this is a tradeoff we must accept to avoid run-time download of crucial binaries.

Ok so after having thought out loud above, i think overall it's the right direction.