TIL: #Mastodon specifically treats actor URIs with the pattern `https:///actor` as instance actors.'n'n #fedidev #ActivityPub
Technical Discussion
3
Posts
2
Posters
2
Views
-
<del datetime="2025-10-12T21:34:00+09:00">TIL: #Mastodon specifically treats actor URIs with the pattern
https://<domain>/actoras instance actors.</del> <ins datetime="2025-10-12T21:34:00+09:00">Turns out I misread the code. 😅</ins>#fedidev #ActivityPub
-
System shared this topic on
-
Where are you seeing this?
Mastodon does serve its instance actor as
/actor, however it doesn't actually track the "instance actor" as a concept, because there's actually no way to do so. fep-2677 doesn't define one, it just says the instance actor must be an Application, and adds a reference to that actor to NodeInfo.That is, from the actor document alone, there is no way to know if it is the "instance actor" (remembering too that AP doesn't have any notion of an "instance" or "server")
Likewise, internally in Mastodon, the instance actor record will have the ID of -99.
-
@thisismissem@activitypub.space Ah, I seem to have misread the code. I was confused by Mastodon serving its own instance actor from
/actor. Thanks for the clarification!
Gli ultimi otto messaggi ricevuti dalla Federazione
-
fentiger@mastodon.social yes I was also thinking of the venerable 429.
evan the thing is, both approaches rely on the receiving end to support it. I would make the argument that a 429 would have nominal support from some implementations, but then again I wouldn't actually bet money on it.
Either way you're looking at an FEP to establish flow control signalling or 429 handling. I'd then make the argument that putting together guidance for 429 (+ exponential back off) is easier than specifying flow control logic.
-
@evan No, you haven't. You just need to back off and retry, just as you do for an ACK timeout in TCP.
-
fentiger@mastodon.social yes, but by that point you've failed. What I want is to have more adaptive sending, so you don't get to the 429 code.
-
-
Obviously the other option is to keep sending until the receiving server fails, and then do exponential backoff until the remote server can process your activity again.
But I'm looking for something more adaptive that adjusts the sending rate before the receiver fails.
-
I've been thinking lately about flow control. That's a feature of some networks where a receiver can tell a sender to slow down its sending rate to match the receiver's processing rate.
In TCP flow control, the receiving host returns a receiving buffer size in its acknowledgement segment, so the sending host know how much data it can send without overflowing the buffer.
I wonder if there are ways that a receiving ActivityPub protocol server could tell the sending server to slow down? Maybe we could reuse some of the RateLimit headers.
Another option would be a special header that says how big your incoming activity queue is. "I have a very long processing queue right now, please keep stuff in your outgoing queue for a while."
-
@flancian It's an egregiously backwards-incompatible change, so probably no.
-
@julian Pages should be real containers, not slices of the collection like "last 25 items".
