Most Lemmy instances currently use an allowlist based federation, so federation with unknown instances is denied. That is good for security, but makes it hard for instances and users to connect. So I want to implement a functionality where server A can send an activity to server B, asking “do you want to federate with me”, and B responds yes or no.
These two issues explain it in more detail:
Now I’m wondering which activities would make sense to implement this, and if any other projects have similar functionality. I believe Peertube does, but their docs dont specify how it is federated. Maybe Offer and Accept/Reject would work, but I dont know what the object of the Offer should be.
PeerTube and Mobilizon both have an instance actor (named root for PeerTube, relay in Mobilizon). Following instances is simply done by following this actor.
The involved activities are simply Follow/Accept/Reject.
Thanks, I guess that makes sense. Out of curiosity, is the follow relationship between instances used for anything else, or just for the federation request?
We provide instance actors as well, however these aren’t always easily discoverable. A concept we’ve used in the Zot/Nomad sector of the fediverse is for queries to the domain root to return information about the site. We use this to obtain keys for providing additional transport encryption.
I’ve had every intention of providing a similar interface to ActivityPub. In this case an ActivityPub/ActivityStreams fetch of the domain root would return an actor of type Service. Don’t look, because it isn’t there at this moment. Having worked with instance actors for several years it turned out to be a logical and intuitive progression to place it at the domain root. This could be useful in a number of scenarios such as notifications/reports/blocks to a site admin or admin team; who likewise aren’t always easily discoverable and could be implemented as an alias for the existing instance actor on projects that already use this concept. The point being that for accept-only sites this Service actor could also be followed which would provide an easily discoverable way to connect sites. And a “manuallyApprovesFollowers” field in that record with a value of ‘true’ could potentially indicate whether or not the site itself was open or closed to the rest of the fediverse by default.
I’ll just throw this idea out there in case anybody else sees value in it. If not, no big deal.
It wasn’t so much the concept of service actors I was recommending - in fact a fair number of projects have them already and use them internally. In my view what actually gives them added value is to put them on the domain root so that they are easily discoverable; and we could use that “actor” record to provide site profiles rather than requiring us to query platform specific APIs to discover stuff about remote sites. We’re “trying” a fair number of these platform specific APIs at the moment and I know Friendica hits some sites with about 10-15 discovery fetches just to determine what they are and how they communicate. This seems wasteful; but it’s necessary because there’s no standard site discovery mechanism.
This could take sites to a whole new level. Especially if it opens the possibility of relationships and eases reporting content and notifying admins of issues across platforms – which are unable to support/implement the Mastodon API because their internal architecture is radically different.
I really like this idea. In fact I was wondering where to put the instance actor, but doing something like lemmy.ml/lemmy seems slightly awkward. Putting it at the root makes a lot of sense, and I dont see any argument against it.
Good point, I think this could be a really elegant way for us to federate reports.
Most of our sites turn off nodeinfo because they are private sites run for family and friends and don’t like handing out usage and malware targeting statistics to strangers.