search

neighbour-hoods / nh-launcher

Creating a group coherence with holochain apps
Other
4 stars 3 forks source link

[BUG] Cannot install large WebHapp bundles #43

Closed pospi closed 6 months ago

pospi commented 1 year ago

This affects the Timetracker applet with embedded larger hREA DNA files.

Unfortunately my research has shown me that this is a more complicated fix than anticipated, that may require upstream changes (both filesystem paths and BLOB data are needed in order to process an installation fully). Awaiting info from others on the current situation with NH Launcher vs other Launcher apps (We's and Holochain's).

pospi commented 1 year ago

See also:

https://github.com/tauri-apps/wry/issues/87#issuecomment-680069431 https://github.com/tauri-apps/wry/issues/87#issuecomment-915054980 https://tauri.app/v1/api/js/dialog https://tauri.app/v1/api/js/fs https://tauri.app/v1/api/js/event/#listen

Probably not going to implement drag & drop for now (second & fifth links), for polyfilling reasons of weirdness that may break other drag & drop functionality in applications.

pospi commented 1 year ago

@matthme I wonder if you'd be able to point me to changes in the Holochain Launcher which switch to the new APIs for direct *.webhapp installation through the conductor? I was hoping I'd be able to port them here fairly easily.

matthme commented 1 year ago

There is no such API for apps to use that are installed into the Holochain Launcher. What you could potentially do is fork the Holochain Launcher at the commit that you are using it for your nh-launcher and make such an API yourself. If that's an option for you, I may be able to assist you.

pospi commented 1 year ago

Sorry, just looping back on this! I think we may have crossed conversations in the past then.

The last we had discussed RE the Holochain Launcher was that

To be honest, I don't really want to put that [fs.readFile] permission into the official Launcher because I don't want apps to be able to read on the filesystem without user interaction. That would effectively allow malicious apps to crawl the whole filesystem of users... In the new version of We installing apps via javascript will anyway not be required anymore...

pospi — 06/17/2023 10:56 AM How so? Is the subconscious going to support some kind of UI bundle installation so that it doesn't have to be done via an AdminWebsocket in Tauri's browserspace?

matthme23 — 06/17/2023 10:40 PM It's going to be handled in Rust yes. And since that version of We is in control of the conductor/lair-keystore it has access via the AdminWebsocket in Rust is no problem.

and also

the branch that's going to be used for the dweb launcher release is the launcher-hc-beta-0.1-appstore branch (https://github.com/holochain/launcher/tree/launcher-hc-beta-0.1-appstore) that contains the appstore.

pospi — 06/18/2023 3:48 PM This branch will have the direct *.webhapp install feature in it too?

matthme23 — 06/18/2023 9:19 PM Yes yes, sure

So I just want to double check here, but I will take a bit of a look through the Launcher codebase too. But if there is some Rust API I can pass a *.webhapp bundle file path to from within the Launcher UI's host Tauri sandbox then I should be able to wire that up in order to install and register Neighbourhoods Appets the same as Holochain Apps.

Although, I expect there will also be further steps necessary as the NHs launcher needs to inflate and parse a different entrypoint (a CustomElement manifest or similar, rather than the simpler "unpack zip archive and load index.html" for standard Holochain Apps).

If the above "direct install" is possible, the appropriate solution may be to implement a deferred two-part installation for Neighbourhoods Applets. Part 1 is installing the App (not Applet) Bundle into the Holochain App Store. Part 2 is reading the UI bundle code out of the Holochain App Store in order to re-parse its manifest and extract isolated UI components as byte streams; store those into the NH Launcher's interface storage Cell (read: some component of the NH Feature Library as distinct from the Holochain App Store); and subsequently update the corresponding "Neighbourhoods Feature" from 'pending' to 'installed' once all this processing as completed.

matthme commented 1 year ago

I must have misunderstood what you meant with "direct *.webhapp install feature". I thought you were referring to installing a webhapp from the filesystem via the Holochain Launcher user interface.

As I said in my comment above, there is no such API that's accessible for apps that are installed into the Launcher. And I don't think it is planned to add such an API (at least not any time soon) because I don't think the Holochain Launcher is the right container for apps to install other apps themselves (at least it would require rather complex permissioning).

I offered to help you if you want to fork the Launcher and implement such an API yourself for your specific use case. But this kind of discussion we can have in another place than this Github issue thread as this ping-pong here with mutual misunderstandings is unnecessarily time consuming for me.

pospi commented 1 year ago

Per @adaburrows in https://github.com/holochain/launcher/issues/167#issuecomment-1598428997

once we have the Tauri app up and running we can also write our own rust code that runs locally and handle some of these filesystem things.

The Holochain Launcher hc-launch utility implements some logic in prepare_webhapp which we may be able to import and use for this purpose.

Wrapping this utility in some specific Rust function outside the Webkit runtime that can be executed from Tauri's JavaScript execution environment should be reasonably straightforward (it looks like there are macros to do this eg. #[tauri::command]).

pospi commented 1 year ago

@adaburrows just to confirm: should we go ahead and migrate to a standalone launcher app with our own custom Tauri build, as per We?

I was under the impression that We still maintained some ability to be installed as a 'regular' Holochain hApp inside the Holochain Launcher; but if not- well that says something about the limitations of that environment if even We's simplified cross-iframe rendering model isn't able to be modularised within it.

But I do still really like that as a long-term goal, and FWIW I think it could be quite advantageous to be able to "stack" application stores & application runtimes on top of a "standard" Holochain conductor. Mostly in consideration of how mobile device support or lack thereof may show up in future (a single install from Play or the App Store is all you need for all your Holochain-related applications), how tedious centralised software publication processes are (lookin' at you Apple), how complicated the maintenance of multiple Holochain application runtimes may be and what overhead (financial, dev effort, administrative) it may cost the 3 active launcher projects (HC launcher, NH launcher, We launcher) even if we're mostly leaning on Tauri for this.

Suggest we find ways to genericise the additional launcher utility functions we create and submit as upstream improvements to the stock Holochain launcher. (CC @zippy @weswalla)

pospi commented 1 year ago

Details on relevant affected sections of MatrixStore here: https://github.com/neighbour-hoods/nh-launcher/pull/61#issuecomment-1699731505

adaburrows commented 6 months ago

Closing this, since going forward we're going to overhaul how anything from an applet is stored or not stored in the source chain and DHT.

Also, as a note, we did run into this once again when we were updating the Todo applet and imported a new library. It seems that the source chain has a pretty small size for how big entries can be, so we'll need to split applications into much smaller chunks in order to store them properly. I wonder if this issue has struck any apps using the dev hub, or if it's limited to apps stored in the source chain.