It'd be cool if one could open an EventSource on an OrderedCollection to subscribe for changes in a user's outbox, This could be used as a basis for real time chats and games.
Probably needs to be on top of HTTP2/3 to handle more subscriptions over a single connection.
Maybe even with a Triple Pattern Fragments querystring to filter by Activity type/author/cc/etc?
@thisismissem Yup! I've done a lot of work with scaling EventSource, HTTP2, and push based stuff in general. :)
I'm thinking I'll eventually start working on something similar to SOLID pods but more client-side.
@mauve SOLID pods have a Notification Protocol that you might be interested in.
@thisismissem Interesting. Seems to be an order of magnitude more complex than what I had in mind, but it covers a lot more cases which is interesting.
@evan Ah but that is for servers to get data pushed to other accounts' server inboxes not for clients to pull updates from a server.
E.g. a client application would need extra apis specific to their sever to be able to get updates.
I'm into thick clients over implementation specific server APIs. 😅
@mauve oh, right. So, what about Websockets?
@evan Websockets means inventing more wire protocols and is much harder to implement. Server Sent Events are a simple text based standard and have a way to deliniate event types / reconnect logic / etc. Fitting an event stream of AP Activities is a small amount of spec work and implimentation compared to websockets. (cross language too) Also easy browser APIs!
@mauve Cool. I'd implement that.
@evan @mauve I don't really know much about AP, but maybe you could use ReadableStream API?
I was tinkering with SSE, but then came across this via a toot (that itself I can't find): https://github.com/Azure-Samples/chatgpt-quickstart/pull/19/files
@daaain Could you elaborate now how the ReadableStream API applies to this context? Do you mean that folks should parse `fetch()` responses as a binary buffer stream and that that would be used for subscriptions along with a custom NDJSON based wire protocol instead of the EventSource API?
IMO EventSource give us more to work with, but I would agree that NDJSON with a series of Activities would be easy to implement.
@mauve I must admit I'm a bit out of my depth in the context of this thread, but just spotted SSE and remembered the thread where Pamela was explaining how much simpler the implementation was after this change, but it might be totally inappropriate for what you're trying to do, in which case apologies 😅
@daaain No, I think you're spot on with the ndjson stuff. I'm just too web browser brained with this niche api that barely anyone uses. :P opening a request and piping it into an ndjson parser might need a bit more work dependency wise or code wise, but it's also more likely to have easier implementations accross languages. 😅
My experience with bovine flavored Client To Server is:
An EventSource (for Inbox) is roughly what one wants. The browser side implementation of EventSource is however kind of bad, so I had to replace it with a shim.
Next the lastEventId mechanism is kinda nightmarish, as it only works for short reconnects (browser side), not for going offline - online.
Finally, the architecture of ActivityPub does not really work if one doesn't want one big monolithic Actor implementation. Now, that I've switched to AMQP internally, repairing this is kinda on my todo list.
See also this discussion on SocialHub.
@mauve I think this would be interesting, but you've gotta look at the scaling issues that may be faced, and how that data would be consumed.