The logic to update proxies both in the local state (actually accept requests on a new tunnel) and on datum (store the connector and advertisment in the Datum API) currently lives in the ui crate only. See the various save_create_tunnel / save_proxy signals. This is not very clean IMO and quite error-prone. This should all be handled by the TunnelService, which already contains a ListenNode and a DatumCloudClient.
In general, the API should be cleaned up and documented.
The logic to update proxies both in the local state (actually accept requests on a new tunnel) and on datum (store the connector and advertisment in the Datum API) currently lives in the ui crate only. See the various save_create_tunnel / save_proxy signals. This is not very clean IMO and quite error-prone. This should all be handled by the TunnelService, which already contains a ListenNode and a DatumCloudClient.
In general, the API should be cleaned up and documented.