Feature Improvement: Client Side Wallet Creation via query parameter reflection

[farscapian]

If we can configure the web server (e.g., nginx) that serves Clams Remote build output to reflect query parameters back to the client (e.g, via HTML Injection or response headers), the wallet could be instantiated client-side. This feature would side-step the need for a long-running server process to handle URLs, and make the whole process more suitable for immutable deployment.

[lnbc1QWFyb24]

We are thinking of changing our approach to Clams to work on making it focused on self hosting, which would involve going in the other direction by making the app a server side rendered app and then we can build the proxy in to the app itself. That way the app could connect directly to a node on the same host via the proxy, even if the node is running over TOR. Would like to get your thoughts on this though and to understand why a long running server process is not ideal for deployment.

[farscapian]

Let me try to throw some reasons out there why I'm leaning this direction. I understand there are probably a lot of good reasons to go with server-side rendering, but consider this:

A Hackathon idea I wanted to eventually implement was making Clams Remote static build output accessible via a Pear Runtime endpoint in a manner similar to Keet. The optimal thing to distribute there would be the static build output, since at the end-of-the-day, Clams Remote is a Progressive Web App that runs in the browser. By distributing the static build output and NOT relying on some server-side process, you can essentially eliminate server hosting costs (self-hosting or third-party). This is the ideal case that we should strive for IMO. Users should theoretically get better performance since you won't have to make network round-trips to a backend webserver to fetch various routes (since the entire pear://clams-remote-pwa is distributed as an atomic unit, like an app). This simplifies static analysis of the app too, since you only need to assess the security of the static build output (html, css, js). Since there would be no server-side process at all, we would have to add a "Scan Connection QR" option in Clams Remote since there would be no web server to submit a query string to.

IMO to second-best situation (case 2) is the self-hosting case, where the Sovereign User self-hosts the Clams Remote static build output in a basic web server (such as with the current Start9 implementation). In this case, the server infrastructure complexity goes way down (it's a simple nginx webserver compared to a large node-based image). In this case, the web server can reflect the query string back to the PWA caller. Though from a security perspective, giving the web server access to the credentials at all would be a least privilege violation imo. (Again, the best case is the one above where we eliminate the server process entirely by distributing the app on a pear-like swarm, similar to Keet). Because there's a web server involved, the PWA must be loaded via network round-round trips, though performance in the respect is usually very good since it's cached static output.

Case 3 would be to self-host a server-side rendered app, as ya'll are suggesting. If you go this route, you preclude the possibility of Case 1 altogether, and Case 2 is has degraded functionality). In addition, my experience has been that the clams-remote node-based server process is very slow without some other caching strategy in place.

The least favorable situation (case 4) is third party hosting of the app, such as at remote.clams.tech. I fully agree with your push towards self-hosting, but I don't want you to preclude the ability to distribute the app via some swarm.

[lnbc1QWFyb24]

Yeah that makes a lot of sense @farscapian and I think it might be the way to go by focussing on a single static build. I was thinking along the lines of improving the connection process on Start9 to no need TOR for connection, but then I realised that SSR would not fix that. I believe Start9 is introducing clearnet support over VPN soon anyways.

I think we can achieve the functionality described in this issue without any major changes. In your nginx config do you have it set so that no matter the route, it always reroutes to /200.html? That might even solve the issue...

[lnbc1QWFyb24]

https://kit.svelte.dev/docs/single-page-apps#apache There are specific instructions for Apache to serve as a single page app, so maybe something similar is needed for nginx?

[farscapian]

I've been trying to find the right nginx.conf configuration for months! After multiple attempts and with your help @lnbc1QWFyb24 , I found the correct configuration for nginx! It was so simple! And you were correct, the "query parameter reflection" is unnecessary! It works already! I stumbled on this post which helped me figure this out https://khromov.se/the-missing-guide-to-understanding-adapter-static-in-sveltekit/

http {
    include mime.types;
    sendfile on;

    # server block for clams remote
    server {
        listen 80;
        server_name 127.0.0.1;
        root /usr/share/nginx/html; 
        index index.html;

        error_page 404 =200 /200.html;
        error_page 403 =200 /200.html;

        location = /200.html {
            internal;
        }
    }
}

I'll be submitting a PR subsequently for https://github.com/clams-tech/clams-remote-startos so it has the correct NGINX config. I suspect this will fix the refresh issues that are outstanding for the project.