You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several features would benefit from or require the existence of an ActivityPub actor representing a Mastodon instance. This actor could for instance be used to sign every fetch request (unless fetching on behalf of a specific user), or be used as a relay for “friendly instances” or allowing people to subscribe to whole instances (which are features Pleroma have), and maybe even use that for anonymous federated reports instead of the designated contact (or the first non-banned user if it isn't set).
Technical considerations
If we do introduce a new actor representing an instance, and especially if we do sign fetches with it, we probably want it to be resolvable by existing Mastodon instances. Therefore, it must have a preferredUsername that is accepted by Mastodon and allows looping back to the actor itself. Having a look at how the Mastodon codebase changed throughout history, it seems there is a pattern of usernames that have always been accepted for remote users but not for local ones: usernames containing a dot. Therefore, we could use instance.tld as a preferredUsername, thus having a acct:instance.tld@instance.tld acct URI for that actor.
On the other hand, we want to make it obvious to old and new instances alike that those actors are “special”. There are multiple way to do this:
Have an url and id use a different scheme than any other account, say https://instance.tld/instance-actor, with a special HTML representation
Have an Application type (supported since 2.4.0… so signing would still break things for instance between 2.3.0 and 2.4.0…), which would mark it as a bot and be different from our usual “This account is a bot” checkbox (which uses the Service type)
The text was updated successfully, but these errors were encountered:
voicing support for Application actor type that has instance.tld@instance.tld as a webfinger lookup. or maybe even just instance.tld -- e.g. how bridgy-fed uses @instance.tld directly instead of requiring a username.
Motivation
Several features would benefit from or require the existence of an ActivityPub actor representing a Mastodon instance. This actor could for instance be used to sign every fetch request (unless fetching on behalf of a specific user), or be used as a relay for “friendly instances” or allowing people to subscribe to whole instances (which are features Pleroma have), and maybe even use that for anonymous federated reports instead of the designated contact (or the first non-banned user if it isn't set).
Technical considerations
If we do introduce a new actor representing an instance, and especially if we do sign fetches with it, we probably want it to be resolvable by existing Mastodon instances. Therefore, it must have a
preferredUsername
that is accepted by Mastodon and allows looping back to the actor itself. Having a look at how the Mastodon codebase changed throughout history, it seems there is a pattern of usernames that have always been accepted for remote users but not for local ones: usernames containing a dot. Therefore, we could useinstance.tld
as apreferredUsername
, thus having aacct:instance.tld@instance.tld
acct URI for that actor.On the other hand, we want to make it obvious to old and new instances alike that those actors are “special”. There are multiple way to do this:
url
andid
use a different scheme than any other account, sayhttps://instance.tld/instance-actor
, with a special HTML representationApplication
type (supported since 2.4.0… so signing would still break things for instance between 2.3.0 and 2.4.0…), which would mark it as a bot and be different from our usual “This account is a bot” checkbox (which uses theService
type)The text was updated successfully, but these errors were encountered: