Would advise waiting until the v0.2.0 PR is merged #1565.

The majority of the notification work is done by generic classes so specific channel types only have to implement the parts specific to them. At a first glance the biggest part for this one would be to support authorized GET requests on the receiveFrom URL.

Each resource could advertise in their Description Resource a pre-established notification channel which has the resource as it's topic.

This is the part that would make things more difficult as currently we only do discovery through the storage description resource, not the metadata of specific resources. I have been thinking of adding that as well in the future but would require some internal changes to support adding custom metadata on a per-resource basis.

Thank you @joachimvh, I'm definitely going to wait for #1565 to land first!

I see no problem with first adding support for Streaming HTTP on par with the support for Websockets, later iterating on adding more features.

At a first glance the biggest part for this one would be to support authorized GET requests on the receiveFrom URL.

I'm planing to create issue on the notifications spec to make AuthN explicit for each channel. This way we can also use Capability URL for Streaming HTTP notification channels, later enabling ones which rely on Solid-OIDC directly on receiveFrom.

Given all above I would see 3 iterations for Streaming HTTP support:

1. Discovery via storage description resource, subscription step specifying topic and Capability URL based channels (practically the same as current websockets)
2. Discovery via storage description resource, subscription step specifying topic and Solid-OIDC AuthN directly on receiveFrom
3. Discovery via Resource Description, a pre-established channel using the resource as its topic and Solid-OIDC AuthN directly on receiveFrom

Each step only enables additional functionality without changing functionality added in a previous step. Does it sound reasonable?

Note that when I say this would be the biggest part I don't see it as being a big hurdle, but more that this is the main part for which an extra class would be needed. But this should not be a major issue when implementing since it can reuse the authorization functionality already in CSS (which is what happens when subscribing). So immediately going to step 2 would be fine.

I see the upcoming documentation for WebSocketChannel2023, this is very helpful!
Once it lands I will most likely just try to mimic it for StreamingHTTPChannel2023. We still haven't addressed making auth scheme explicitly solid/notifications#155 I think it might be a bit easier to first add support for channels relying on capability URLs since it should be pretty similar to how WebSockets are going to work.

I might be able to work on this feature by adding it as an extra task to a project with NLnet, which I'm currently wrapping up. If it happens, I hope to have StreamingHTTP available before the Solid Notifications session planned for https://events.vito.be/sosy2024

To make it more clear how it differs from WebSocket, I plan on taking the following approach:

1. Authorization always happens on the request to receieveFrom URL
2. Each resource always has one notification channel created for it, similar to an auxiliary resource
   a) The notification channel is advertised in the description resource or even in the Link header of the resource itself, similar to old websockets that had Updates-Via; this would remove the need for an extra request to the description resource.
3. All clients (and users) use the same channel for a given resource; I don't plan to have a subscription service for StreamingHTTP since each resource will have its channel created, again similar to auxiliary resources.

I still need to look at how the handler of receiveFrom can store http responses in a Map, so chunks with notifications can be written to those responses in the StreamingHTTP2023Emitter. Similar to how WebSocketMap stores websockets and sends messages to them in its emitter.