Server-sent Events for the ActivityPub API
-
One of the user stories for the ActivityPub API task force is to enable real-time updates for clients.
https://github.com/swicg/activitypub-api/issues/9
To help with this, I added a draft specification for server-sent events:
https://swicg.github.io/activitypub-api/sse
If you're interested, please review and provide comments on the GitHub issue. I'd like to start a reference implementation soon.
-
One of the user stories for the ActivityPub API task force is to enable real-time updates for clients.
https://github.com/swicg/activitypub-api/issues/9
To help with this, I added a draft specification for server-sent events:
https://swicg.github.io/activitypub-api/sse
If you're interested, please review and provide comments on the GitHub issue. I'd like to start a reference implementation soon.
@evan There was some discussion of this on SocialHub a while back: https://socialhub.activitypub.rocks/t/fep-proposal-c2s-websocket-endpoint/2955
Or you might have been aware of it already, in which case, sorry for the noise
-
One of the user stories for the ActivityPub API task force is to enable real-time updates for clients.
https://github.com/swicg/activitypub-api/issues/9
To help with this, I added a draft specification for server-sent events:
https://swicg.github.io/activitypub-api/sse
If you're interested, please review and provide comments on the GitHub issue. I'd like to start a reference implementation soon.
evan makes a ton of sense! The ActivityPub API doesn't have a subscribe mechanism, so this makes sense.
SSE also makes sense vs web sockets. There are plans on our end to establish SSE as well, and deprecate our own websocket implementation.
-
@evan There was some discussion of this on SocialHub a while back: https://socialhub.activitypub.rocks/t/fep-proposal-c2s-websocket-endpoint/2955
Or you might have been aware of it already, in which case, sorry for the noise
fentiger@mastodon.social Thanks, I'll look through it for ideas.
-
evan makes a ton of sense! The ActivityPub API doesn't have a subscribe mechanism, so this makes sense.
SSE also makes sense vs web sockets. There are plans on our end to establish SSE as well, and deprecate our own websocket implementation.
Yeah I went the SSE route too. Nice n simple.
-
Yeah I went the SSE route too. Nice n simple.
The problem for us is that we actually did take advantage of the bi-directional data flow available with web sockets. However, probably > 90% of our websocket calls were simple data requests, so we dropped back to bog-standard GET and POST. Why re-invent the wheel?
It's that other half where you want to communicate events in real-time, where SSE makes sense.
