TIL: #Mastodon specifically treats actor URIs with the pattern `https:///actor` as instance actors.'n'n #fedidev #ActivityPub
Technical Discussion
3
Posts
2
Posters
18
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
-
@julian 😘
-
pfefferle@mastodon.social how has nobody complained about that yet? 😂
-
-
Hey pfefferle@mastodon.social nutomic@lemmy.ml, I'm looking to integrate support for postingRestrictedToMods
I see some discussion here:
https://github.com/friendica/friendica/issues/14377It's a little specific, but even so, I'm happy to add it, since it solves some issues with cross-community content creation permission.
Is there a JSON-LD context I can add, since I am assuming that postingRestrictedToMods is not standard?
-
@silverpill regarding pagination, I do
next=URL encoded ID of the latest item in the items' collection
prev=URL encoded ID of the first item in the items' collection.
This is very verbose, but I haven't found a better solution that doesn't require additional storage or context (like DB ids for example).
As always, for examples you can look at federated.id:
-
@mariusor I've started to collect information here: https://codeberg.org/silverpill/feps/src/branch/main/9f9f/fep-9f9f.md
-
@silverpill yes, I was thinking of the nomadic identity aspect when I said that.
So, for GoAP: a user wants to upload an image, it can specify recipients, the client builds an Image AP object out of that (including a reply collection) and wraps it in a Create collection, sends it to the server (C2S).
Server saves Image locally, creates all collections for the Image that are not empty in the Image (like replies, likes, shares, etc) adds it to outbox of user's Actor, adds it to local follower's Inbox or sends it to remote followers Inbox (S2S). If it's in reply to something(s) loads the object(s) and disseminates it to the recipients.
-
@mariusor I understand, and this is not a criticism of your implementation. I think the problem I described is not limited to nomadic AP, the vanilla specification doesn't tell us how clients should work with collections, so we need to figure it out by ourselves and document in a FEP.
>we're limited to plain Activity vocabulary.
replies is a part of the vocabulary. Does your server support it?
