Server-sent Events for the ActivityPub API
Technical Discussion
6
Posts
4
Posters
0
Views
-
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 SocialHib 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 ;)
-
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 SocialHib 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.
-
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.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
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.
-
Yeah I went the SSE route too. Nice n simple.
-
@evan this is what happens when you read the fedi at stoplights.
I'd think some kind of link to the "triggering" activity in the result.
(I'm speaking from a very old and rusty memory of AP, but)
Is a result an activity? Can it live on it's own? If not, it seems like a processor can make the assumption that object → result? Otherwise, a link to the triggering activity by id could work. But what to call that link? <shrugs>
-
sivy@hachyderm.io I used an example in my original post! The result property describes this relationship.
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-result
Here are a few more:
When an actor arrives at a place, the actor updates their own location When an actor likes an object, the actor adds the object to their liked collection When an actor unfollows someone, the actor removes that someone from their following collectionSo, I see it particularly useful for the side-effects defined by ActivityPub, but there may be other good uses.
-
@evan I don’t know just random driving thoughts
-
@evan@activitypub.space @evan@cosocial.ca i.e. can another activity be considered a cause which raises the question of whether an activity stream stream can be considered a network graph delivered overtime
-
@evan hi Evan, I think we would need some examples of what you consider a cause to be in order to develop this idea further
-
fentiger@mastodon.social Thanks, I'll look through it for ideas.
