android-apps-mirrors/SimpleX-Chat
0
0
Fork 0
mirror of https://github.com/simplex-chat/simplex-chat.git synced 2025-06-28 20:29:53 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

rfc: remote UI implementation (#3206)

Browse source
This commit is contained in:
Evgeny Poberezkin 2023-11-16 21:53:54 +00:00 • committed by GitHub
parent 64f0dbeb61
commit d0f3a3d886
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 107 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

25
docs/rfcs/2023-09-12-remote-profile.md
View file

@ -125,9 +125,10 @@ Alternatively a mobile (or a desktop, why not) may signal that they're done here
At any time a user may click on a "cancel" button and return to the main UI.
That should fully re-initialise UI state.
In the "Network & servers" section of "Settings", there is an item to list all the registered remote controllers with buttons attached to *dispose* them one by one.
*Disposing* a remote controller means its entry will be removed from database.
Future connection attempts from a disposed device would be treated exactly as from a previously-unknown device.
This screen should have a way to open the list of all known remote controllers (desktop devices), to allow removing them.
*Removing* remote controller means its entry will be removed from database.
Future connection attempts with a removed desktop will be treated as with a previously unknown device.
### On a desktop device
@ -148,8 +149,9 @@ Future connection attempts from a disposed device would be treated exactly as fr
4. A user may open sidebar and click "disconnect from mobile" to close the session and return to local mode.
* That should fully re-initialise UI state.
In the "Network & servers" section of "Settings", there is an item to list all the registered remote hosts with buttons attached to *dispose* them one by one.
*Disposing* a remote host means its entry will be removed from database and any associated files deleted (photos, voice messages, transferred files etc).
Unlike mobile UI, removing known mobiles should happen via the same screen that shows connected mobile deivices.
*Removing* a remote host means its entry will be removed from database and any associated files deleted (photos, voice messages, transferred files etc).
## Caveats
@ -192,9 +194,20 @@ A backup system may be implemented by attaching a headless app to a bouncer as o
The unauthenticated remote host can be considered a feature.
A use case for that may be something like a "dead drop" host that wakes up in response to any discovery broadcast.
## Unresolved questions
## Other questions
- What to do with WebRTC/calls?
Calls use local desktop implementation, they will use host for signalling.
- Do we want attaching only to a subset of profiles?
No.
- Do we want a client to mix remote and local profiles?
No.
- Do we want M-to-N sessions? (follows naturally from the previous two)
No.

88
docs/rfcs/2023-10-12-remote-ui.md Normal file
View file

@ -0,0 +1,88 @@
# Remote desktop / mobile implementation details
This follows the previous RFC for [remote profiles](./2023-09-12-remote-profile.md).
Code uses terms remote controller and remote host to designate the roles, and CLI client can support both.
This document uses the terms "mobile" to mean remote host and "desktop" to mean remote controller, mobile apps will only support "remote host" role (via UI, and, possibly, via the compilation flag to remove this functionality from the code), and desktop will only support "remote controller" role.
## Mobile (host)
UX is described [here](./2023-09-12-remote-profile.md#on-a-mobile-device).
When mobile is connected to the remote desktop it will receive no events from the core (other than remote session connection status changes), and the core will accept no commands from the UI (other than to terminate the remote session).
As currently mobile maintains the list of connection statuses for all profiles, this state will have to be maintained in Haskell to be able to send it to the remote desktop UI when it is connected. It will also be used to update mobile UI when control is returned to the mobile.
The switching between remote host role and local UI role should prevent the possibility of any race conditions.
To swith to remote host role:
- UI: will show the screen with "connected" status and "cancel" button, with disabled sleep timer on iOS, as iOS app will have to stay in foregro. Android will be able to function in background in this state.
- core: stop adding events to the output queues (via some flag).
- UI: process remaining events in the output queue and stop receiving them.
- core: stop sending events to and accepting commands from UI.
- core: send current list of profiles, coversations, and connections statuses to the remote desktop.
- core: start sending events to and accepting commands from remote desktop.
- core: start adding events to remote output queue.
To switch back to local UI role:
- core: stop adding events to the output queues.
- core: stop receiving commands from and sending events to remote desktop.
- remote desktop: receive pending events and stop processing them.
- UI: load current list of profiles, conversations, and connection statuses from the core.
- UI: start receiving events
- core: start sending events to and accepting commands from local UI.
- core: start adding events to UI local remote output queue.
Possibly, there is a simpler way to switch, but it is important that the new events are applied to the loaded state, to avoid state being out of sync.
## Desktop (controller)
Desktop can either control local profiles ("local host" term is used) or remote host(s)/mobile(s). Only one host, local or remote, can be controlled at a time. It is important though to be able to receive notifications from multiple hosts, at the very least from local and mobile, as the important use case is this:
- mobile device only has contacts and important groups to save the traffic and battery.
- desktop has large public groups.
So while reading large public groups the users should be able to receive notifications from both mobile device and local profile(s).
That means that while only one host can be active in desktop, multiple hosts can be connected.
Current UI model contains:
- the list of the conversations for the chosen profile.
- the list of the user profiles.
- the statuses of connections across all profiles - this is maintained because the core does not track connection statuses.
As the core will start maintaining the connection statuses, as a possible optimisation we could reduce the connections in the UI to only the current profile and reset it every time the profile is switched.
In addition to the above, the UI model will need to contain the list of connected remote hosts (mobiles), so that the user can switch between them.
Switching profile currently updates the list of conversations. If connection statuses are narrowed to the current profile only, they will have to be updated as well.
When switching host (whether to local or to remote), the UI will have to:
- update the list of profiles
- update the list of conversations for the active profile in the host
- update connection statuses, either for all profiles or for the active profile only - TBC
When connected to remote host, or possibly always, UI will have to use the extended FFI to indicate the host in all commands (e.g., to allow automatic file reception in inactive hosts) - as the core cannot simply assume which host is active. Probably, some of the commands (most of them) should require the host to match the currently active host in the core, file reception will not require that.
### Onboarding and "only-remote" desktop
Majority of the users want to use desktop in "remote-only" role, when there is no local profile. Currently, it is a global assumption that the core has an active profile for most commands. Possible solutions to that are:
- update core to allow functioning without local profile.
- create an invisible phantom profile that won't be shown in the UI but will be used by the core to process commands related to remote hosts (connected mobiles).
The 2nd option seems simpler. The phantom profile will use an empty string as display name, and, possibly an additional flag to mark it as phantom. Once a real profile is created this phatom one can be removed (or can be just abandoned). It might be better to block most commands for this phantom profile?
Onboarding on desktop will need to be re-implemented to offer connecting to mobile as primary option and creating a local profile as secondary, and from the users' point of view they will not be creating any local profiles.
## Loading files
Currently active UI, either remote (desktop) or local (mobile), will be making the decision to auto-receive file, based on its own local settings. It seems a better trade-off than alternatives, and also allows for different auto-receive configurations based on the device.
Forwarding received and uploading sent files to/from desktop is already implemented.
It is still required to implement both commands API in FFI layer and, possibly, HTTP API to download files to desktop when they are:
- shown in the UI for images.
- played for voice and video messages.
- saved for any other files.