Recent searches
Search options
Administered by:
‘Given almost all popular Fediverse clients are using the Mastodon Client API, many servers have decided to implement it to support those clients.
The Mastodon team has requested that server implementers not do this, but the lack of any good alternative will result in this practice continuing.’
https://socialhub.activitypub.rocks/t/nextgen-activitypub-social-api/4733
@js It's entirely possible to build on top of the core ActivityPub API (CRUD + follow + collection management). I think it's a great thing to work on.
I think it's a good idea to take it piece by piece. I've done some work on this with the `blocked` collection FEP, `pendingFollowers`, and so on. We need to keep that momentum going.
We can even merge popular extensions into the context file for Activity Streams 2.0 so they become indistinguishable from core.
@evan I like the piece by piece approach.
Is there an FEP for streaming? That's one thing that all good masto clients tap into that I can't squint and see a rough AP analog
@js I don't think so. I think it could be really straightforward -- for WebSockets, change an URL for a Collection from https: to wss: and see if you get a response -- but I don't know if it's written. I'd love to work on it if you would like to collaborate!
@js So, if your inbox is at https://example.com/user/js/inbox, make a websocket connection to wss://example.com/user/js/inbox. If that doesn't work, you fall back to polling.
@js Oh, and obviously the websocket delivers whatever the contents of the collection are -- followers, inbox activities, likes, etc.
@evan @js hiya, I'm the current maintainer on the Streaming server in Mastodon.
I would strongly discourage using websockets for this, and instead preferring Server Sent Events, since these can be both resumable (whereas websockets it isn't built in) and because a websocket setup would require a subprotocol to be defined.
That and scaling websockets can be really complicated.
https://developer.mozilla.org/en-US/docs/Web/API/EventSource
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events
@evan @js so for instance, you can have the SSE stream send the "id" property, which enables you to pick up where you left off, before catching up to the head of the inbox stream
This allows better resiliency on flaky networks, since you're not dropping messages.
Websockets and SSE in Mastodon are currently lossy due to how we receive the events (redis pubsub)
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events#id
@js It's harder for remote collections. I think we'd have to extend how `proxyUrl` works to allow it. `proxyUrl` works with a POST request, which I think won't work for wss:.