Now that we have multi-machine arcologies, the next step is to support semi-trusted local accelerator processes that run on a user's machine to boost performance. Some examples:
- For Luminous, a local accelerator can devote user-resources (local CPU) to the task.
- There are some cases where a local accelerator could operate on large local data without transmitting it all to the server. For example, a local accelerator could access local sprite files and stitch them into a sprite sheet without sending anything to the server.
- Similarly, a local accelerator could serve as a cache for large files (but the server has the authoritative version).
From the user's perspective, local accelerators would work like this:
- User downloads and installs a local accelerator on their machine. Installation would require admin rights and would likely install the accelerator as a Windows service.
- Local accelerator exposes some very simple UI, mostly showing status. Critically, however, it exposes UI for the user to sign in.
- The user signs in to their server account, which gives the local accelerator a token to prove to the server that the user has authorized it.
- As soon as the accelerator is signed in, there is UI on the server which shows the status of the accelerator to the user (probably off the user/account page).
- This server UI might also control permissions, so the user can control which services are allowed to access the accelerator (and what permissions they have). For example, the user might choose to allow an accelerator to provide CPU access but not file access.
- [Once connected, the accelerator automatically downloads whatever additional .exes it needs. For example, Luminous might have a separate .exe. These are automatically installed and updated with no need for user intervention.]
- Services that support accelerators would expose their own UI. For example, Luminous might expose a UI to access image files from the local machine.
Local accelerators will usually be behind a firewall, so will not be able to accept connections from the server. We will need to have a persistent connection to the server which the server uses to ping the local accelerator. On a ping, the accelerator can connect to the server to get its instructions.