Date: 24.01.2024 17:00 (UTC+1) Call: https://meet.jit.si/solid-operating-system Previous meeting link Next meeting link Chat: https://gitter.im/solidos/solidos Repository: https://github.com/solidos/solidos Meetings home: https://solidos.solidcommunity.net/public/SolidOS%20team%20meetings/ Present attendees Tim, Rahul, Chase, Alain

Half Day (2 sessions) PC Rahul Gupta, India elf Pavlik, Mexico/Poland Description HTTP was originally designed to transfer a static documents within a single request and response. But web-applications today are dynamic, providing (near-)instantaneous updates across multiple clients. The notification protocols in Solid cater to the needs of Solid developers to provide their users with a real-time experience. The "Real-Time" Solid session at the Solid Symposium 2024 will provide an introduction to notification standards within Solid as well as existing implementations within the Solid server and client library ecosystem. The intoduction aims to pave the way for a discussion with the broader community of the Solid developers of the ways in which we can improve the real-time capabilities in Solid as well as the developer experience around it. We could use the time to also consider some of the more involved issues in existing specifications (if such a request is raised in advance). The ideas generated in the course of this discussion can then form the basis for a subsequent hackathon.

SC (as understood by RG): Suppose an authenticated client access a topic resource either via a HEAD/GET or a POST; Is exposing websockets cURL in the header any different from going through subscription process from a security point of view. RG: From what I understand, such a cURL will be a standardized channel specific to a topic, i.e. the client cannot add multiple topics or add features. This is undeirable! While this way would be more performant for a subscribing to a single topic, it will be scale poorly. As the number of topics in a websocket channel increases, using the subscription flow to get a cURL becomes more efficient! The former (SC proposal) will require client to manage each topic separately. However, this way a single websocket can handle all the topics on a pod/server. Therefore, I favour exposing Subscription Service on the header (same as the discovery resource) and let the client subscribe to that with all the topics/features it pleases.