I am going to propose something else, related, but not exactly what was initially proposed in this thread.
Distributed Desktop Applications in a multi-user case employing the Uplink.
The Desktop Application installation package contains an exe (which includes the Uplink and core functionality), a config file and whatever else go along with it.
For Security (Conceptually):
Upon request, the web app generates a config file accompanying an installation package including the obfuscated Uplink Key, a client specific key, and a date-time oriented decryption method that only I know, all transmitted solely by encrypted means utilizing a hash of the client key and dynamic date/time encryption…
Aside from security, each desktop app instance would essentially be a client instance as if the client were accessing app endpoints from a web browser.
In a previous implementation, reminisce of how some of us have used the elevated Uplink server access as a daemon, I considered distributing the desktop application to sit in a wait_forever state, passing functions variably within a function; a concept albeit providing tremendous versatility, unnecessarily exposes server access in a non-trusted environment, and resulting in potential ‘insertion’ type attack vectors.
My train of thought to have the desktop application accept calls from my central app to include updates is to have it poll a queue via authenticated API endpoints.
Would it be better to build an API or to use the Uplink for this case? All the local app does is access a local database on the user’s machine.
I’d love feedback on this approach.