@Tak the way I solve this issue with my ActivityPub server is to expose a root Service actor that represents the whole service.
-
@Tak the way I solve this issue with my ActivityPub server is to expose a root Service actor that represents the whole service.
Asking to follow this actor marks the start of a "let's federate!" workflow.
The service operator can review the follow request and make a decision if to allow/deny it.
If allowed, the service Accepts the request and asks for a Follow in turn so the relationship is mutual.
-
@Tak this gives the added benefit that the list of servers an instance federates with is accessible through the Service's followers collection.
-
@mariusor Right, as a request mechanism that makes sense, but how do you find instances in the first place? How do you know that
federated.place
is an instance you would want to federate with before requesting? -
@Tak in my case this root service I mentioned can be found if you request the https://federated.place URL with Accept header set for ActivityPub: application/activity+json or the other compatible ones.
For mastodon compatible servers I think you could use webfinger to request webfinger?resource=https://federated.place
Both these mechanisms can be seen here:
https://federated.id < root Service
https://federated.id/.well-known/webfinger?resource=https://federated.id < webfinger
How would a service advertise this capability... frankly I haven't gotten that far into thinking about the problem. Currently the server operator adds them manually, but I have no clue if there are better options.
-
@mariusor Yeah, that's what I mean. Imagine the entire fediverse transitions to allow-only. Here I come with my new instance,
federate.cool
. How do I even know what other instances are out there?This is already a bit of a problem with the current primarily permissive setup, except you can kickstart the process by following someone on one of the big instances (m.s) and picking up new stuff from the federated feed. But if you do this in the allow-only world, you still just get the one instance.
Maybe you still absorb activities from nonfederated instances into a quarantined area that moderators can choose to browse?
-
@Tak the "federate to everyone" model that mastodon and mastodon likes use is faulty, IMHO, because it doesn't make use of the addressing capabilities of ActivityPub fully.
This "allow-only" federation mechanism would not supersede your users' right to address activitypub activities to a server that you don't federate with already. It would only cover the activities which are explicitly addressed to the Public namespace.
-
@Tak
So, as a site operator you can try to follow a Service after your users have tried to interact with that server by sending some activity to a remote user on that server. -
@mariusor That's fair enough, but if "federation" in this case only applies to public activities and explicitly doesn't apply to directly-addressed activities, don't we lose one of the primary benefits of allow-only federation? (safety from abusive interactions/replies from random trolls)
Like, in this model, if I make a public post, it federates to trusted.space, somebody interacts with it there and it federates to m.s, and from there to nazis.cool, suddenly there are 1000 nazis who can reply to it, right? And my allow-only server won't reject those replies because they're directly addressed?
-
@Tak my words were meant for the outbound direction.
For inbound, I don't know... my personal feeling is that yes, until the instance is explicitly blocked it should receive from instances it's not explicitly federated with. Probably this would be what they call "an implementation detail", any server can use the logic it wants.