Replies: 2 comments 1 reply
-
I feel like we've walked backwards into this being the obvious solution that seems right. The only possible concern I could imagine is if a front-ends needs to connect to many apps at once -- so many that it overwhelms the browser to have all those websocket connection open (i.e what's happening with NOSTR clients). To leave open that ability to support many app connections without requiring many websockets, I propose that rather than binding an app websocket to a single app, it is bound to a discreet list of apps, which could be one, or could be several. |
Beta Was this translation helpful? Give feedback.
-
Agreed, I have just finished implementing code for HoloNET that manages a pool of client websockets (1 for each app), which are allocated by the port returned from the admin api call "attach_app_interface". I was considering sharing a client web socket but it felt more right to do it this way because of the attach_app_interface call so glad I got it right! ;-) The number of connections opened for many apps was also a concern of mine but because HoloNET is desktop it isn't as much of an issue as a browser unless there are a crazy large amount of them! ;-) Although it can also be embedded into browsers or phones etc and then it would be an issue having too many connections... |
Beta Was this translation helpful? Give feedback.
-
Background
At the moment the app websocket (ws) is a general interface which allows for communication with any app installed in the conductor. This enables clients connected to the app ws to make calls across applications.
In practice the predominant pattern is one client connected to an app ws per app. The Holochain core team encourages app devs to adopt this pattern by shipping the JS client with a constructor that requires an app id.
Apart from this pattern, making cross-application calls is a security concern. There are calls available on the app ws to create, disable and enable clone cells, next to the zome call to execute zome functions. If these are made from a malicious client, they can modify another app's state and, depending on the zome functions, lead to data corruption or loss.
Another aspect in this consideration is that app signals are broadcast to all apps, and thus the general app ws receives these signals from all apps. The JS client filters the signals by app id, so again the pattern leans towards tying the app ws to an app.
Suggestion
The suggestion is to bind the app websocket to a specific app on the conductor side. This would address both problems raised earlier. A connected client would only be able to execute calls to that particular app and not to any other app. Additionally app signals would only be sent to the corresponding connected app ws for that app.
Beta Was this translation helpful? Give feedback.
All reactions