Push based- Incorporate Server-Sent Events (SSE)

[linussec]

Problem Statement: Current implementations leveraging PUSH (RFC 8935) require receivers to have publicly exposed endpoints. This setup complicates real-time communication and scalability.

Proposal: Integrate Server-Sent Events (SSE) as an option alongside PUSH to facilitate real-time communication without the need for receivers to maintain publicly exposed endpoints. SSE enables a server to push updates to clients over a single, long-held HTTP connection, reducing HTTP request volume.

Some benefits:

• Reduced Complexity: Eliminates the need for receivers to manage exposed endpoints.
• Enhanced Efficiency: Minimizes the number of HTTP requests, lowering server load and network traffic.
• Improved Security: Decreases exposure to attacks that target publicly accessible endpoints.
• Real-Time Updates: Enables efficient, real-time updates without constant polling, improving user experience.
• Ease of Implementation: Leverages existing web standards, ensuring wide compatibility and simplifying adoption.

[timcappalli]

Server Sent Events is a web technology for client to server server to client communication.

SSF is designed as a server to server event framework.

[FragLegs]

I think you meant to say "server to client communication". And that is a match for the Transmitter to Receiver flow of SSF. While Server Sent Events are commonly seen in frontend applications, there are plenty of libraries implementing Event Source clients in common backend languages like Go, Python, and NodeJS.

For Receivers that are unable to open an HTTP endpoint to receive pushes but still want real-time notifications, Server Sent Events seem like a reasonable solution.

[adeinega]

I support this. There are other ways to communicate events including doing that in a bidirectional way, for instance, WebSockets (which is a decent option in my view).

There should be extension points that enabling SSE, above mentioned WebSockets, etc.

The abstract of the spec states that

This Shared Signals Framework (SSF) enables sharing of signals and events between cooperating peers.

It definitely isn't just "a server to server event framework" the way I read it.

[FragLegs]

Some discussion about this issue happened in the SSF slack. Trying to summarize here:

SSF was explicitly designed to be server-to-server. It is possible to open up other use cases, such as communicating between a server and an entity that is not able to open a push endpoint (i.e. a frontend SPA, a device agent, a firewall, etc), but we would prefer to save those discussions until after a v1 release of the spec. In the meantime, those entities that cannot open a push endpoint have two options:

1. polling - ideally long-polling
2. non-SSF communication with a server that is able to open a push endpoint (i.e. have a normal server as the Receiver and have it open a Server-Sent Events connection down to a SPA)