D2 Notes from standard client data conversation between Joe and Julian

### Description

### Recommendations

1) On the client-side:
1) Add `clientId`, `tabId` , and possibly `pageName` (though that could be derived on the server if preferred) to the socket.io client options `auth` property via a callback function (so that it automatically gets the latest data on every (re)connection). [Ref]([node-red-contrib-uibuilder/src/front-end-module/uibuilder.module.js at v6.8 · TotallyInformation/node-red-contrib-uibuilder (github.com)](https://github.com/TotallyInformation/node-red-contrib-uibuilder/blob/v6.8/src/front-end-module/uibuilder.module.js#L487-L499)). Optionally send a browser timestamp to allow server/browser time offsets to be shared.
2) Add a feature to send a control message to the server whenever the URL Hash changes (to allow for front-end routing)
3) Add incoming message filters on: `clientId`, `tabId` and `pageName`.

2) On the server-side:
1) Add metadata into a `msg._client` property where it makes sense to expose it (connections, messages from the client, etc). Using the same property names as above for consistency. `socketId` can go in there as well or stay on `msg._socketId` (or both?)
2) Add outgoing message filters on: socket id, possibly by page name.

### Socket.IO socket ID: `msg._client.socketId`

Usage: Automatically restrict message sending - at the server - to a specific connection. Usually only reliable for a fairly immediate response to something sent from the client.

Set by: SIO library.
Stability: Only stable across a specific SIO connection.
Restet: If the connection restarts.

### Client ID (UUID): `msg._client.clientId`

Usage: Restrict message receipt - at the client. More stable than the socket id but still does not require any server session management since the id is randomly generated.

Set by: Node-RED server,
Stored in: *browser session cookie*.
Stability: Stable across a browser/server connection.
Reset: If either the browser or the server is restarted.

### Browser tab ID: `msg._client.tabId`

Usage: Restrict message receipt - at the client. More fine grained than client id allowing messaging to a specific browser tab even if client has multiple connections.

Set by: Browser.
Stability: Stable across a browser connection.
Reset: If the browser is restarted.

### Page Name: `msg._client.pageName`

Usage: Restrict message receipt - at the client. But might also allow send restrictions for something like D2. Send messages to ALL connections to that page.

Assumes that separate UI instances have separate URL's so only needs to include the local path, otherwise will need the full URL (minus hash and query parameters).

### Page URL Hash

*NOTE: This needs to be dynamic and so cannot be put into the `auth` property.*

Usage: Restrict message receipt - at the client. Send messages to ANY connections to a specific local route (any client showing that route).

Assumes that the Page Name restriction also used? If not, will need to include more of the URL.

Set by: Browser/page.
Stability: Until user or automation changes the route.
Reset: If the page is reloaded - IF a default route exists.

### User ID

Usage: Necessary for Internet connected UI's and anywhere that needs to identify users and potentially control access.

Assumes that the app is worth setting up and maintaining an Identity & Access Management (IDAM) capability.

Set by: Server IDAM.
Stability: Until user logs out or session expires.
Reset: If the session expires or the user logs out or some other criteria set by IDAM process (e.g. IP Address change).

### Have you provided an initial effort estimate for this issue?

I am no FlowFuse team member