Streamlined workflow to federate with new instances

[Nutomic]

Federating with a new instance is currently quite complicated if it uses an allowlist. It requires getting in contact with the admin through an external method (like Mastodon or Matrix), or making a new account on the Lemmy instance, and asking to federate. Then both admins need to edit their instance config and add the new instance to the allowlist. As Lemmy grows and more instances are created, this will result in more and more work for the admins of big instances. I am proposing a way to automate the majority of this process, and handle it directly in Lemmy.

The following example uses lemmy.ml for simplicity, but it would work identically with any instance.

• There is an admin option "federate with new instance (eg lemmy.ml)"
  • Could display a list of suggested instances from join.lemmy.ml
• After entering instance, fetches and shows info text about the instance (but doesnt federate anything else)
• Button "apply to federate", after clicking shows instructions and message input, eg:
  • Have certain rules/CoC
  • Include a contact method (eg Matrix, Mastodon, Email, etc)
  • Write a short description of their instance
• Submitting the federation application sends an ActivityPub message to lemmy.ml
• Admins accept or deny the application
• If accepted, admins can initiate federation by fetching first user visible items (users, communities, posts, comments) are federated
• Admin posts announcement about federation
  • Currently this would have to be posted by lemmy.ml, so other instances don't block it
  • Maybe we should change allowlist behaviour, so that all posts/comments to allowed instance are allowed (currently we block everything
• Other instance admins see the announcement, and follow the same steps to start federating

This issue replaces #862.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/97091741-removed?utm_campaign=plugin&utm_content=tracker%2F126011972&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F126011972&utm_medium=issues&utm_source=github).

[dessalines]

I think overall this is a good idea, but I'd get rid of the process of "applying" and "voting" to federate. One way this could be streamlined:

• When you first create an instance, have a smart dialog that asks you which type of federation you want to do (open, allowlist, or blocklist).
  • If you click AllowList, then show a picker list of the official instances. (We could externalize this by creating a repo with a json file containing the official instances list, descriptions, links, etc).
• Have a section in your admin settings panel that has that same dialog / federation settings UI component.

This could entail moving the list of federated instances from the config file, to the DB. Or just have that dialog change that federation block in the config for you.

I also don't know that I'd want to do things like automatically announce the new federation. We do that, but not every instance (esp those with open federation) would want to.

If accepted, first user visible items (users, communities, posts, comments) are federated

This one we should talk about more, that would entail doing an API front page fetch, parsing it, and then fetching the first few communities and posts. I don't know if that's a good idea or not.

edit: I spose the main issue here is that federating could easily be handled through lemmy-UI, but its not ( cept through that config file editor in the admin panel )

[Nutomic]

I think overall this is a good idea, but I'd get rid of the process of "applying" and "voting" to federate.

We can leave the voting out, but I think applying is important, because there are many reasons why one instance might not want to federate with another. Otherwise its essentially open federation, and would end up like Mastodon with admins manually sharing instances to block, and thats a huge mess.

I also don't know that I'd want to do things like automatically announce the new federation.

Sorry I didnt mean that this step would be automated, should have clarified.

This one we should talk about more, that would entail doing an API front page fetch, parsing it, and then fetching the first few communities and posts. I don't know if that's a good idea or not.

I'm also not sure how to automate this, I would certainly do it manually at first. Maybe later we can think about automating it.

Updated the original text.

[weex]

I haven't seen what federation looks like in Lemmy for the user. Is there a good example of a sublemmy I can view from lemmy.ml? Or is there another way I can see how federation operates for the user? I think it's important to understand the minimum necessary amount of information that an instance owner would want to know before clicking an accept button.

Edit: Ok, that wasn't that hard to find, just go to All under Communities or even All on the front page. As a potential admin, I'd just want it to be easy to do from one screen. Maybe be able to see basic stats like MAU, # of sublemmies, instance age.

[aschrijver]

First of all I'd like to mention the SocialHub topic that @Nutomic created: Activities for Federation Application?

And I'd like to mention a brainstorming topic I created earlier, namely Federated Moderation: Towards Delegated Moderation? (also cross-posted to Lemmy):

Federated Moderation deals with making common admin and moderation tasks first-class citizens of the Fediverse.

And not app-specific, whenever possible. In addition to sending requests to federate between instances, the Federated Moderation domain (a design pattern: AP vocab extension + rules) would also include:

• Announcing instances to the fediverse, so there's no need for manual maintenance of app-specific lists and instance-collection sites that aren't integral part of the fedi itself.
• Discovery of instances and their metadata as described above (app, federation type, CoC rules, description, etc.).

Note: The mechanism for announcement and discovery closely resembles how the Murmurations protocol by @olisb @geoffturk et al works. This protocol allows you to define JSON-LD profiles to fill in as templates, e.g. a "Federation Profile" and then publish them from an instance (in the case of Murmurations to a centralized index server, where other apps/server can subscribe to. PS. I created a topic to Federate Murmurations protocol, and https://github.com/MurmurationsNetwork/MurmurationsProtocol/issues/30 in their tracker)

[pscodes4fun]

As there are more Lemmy instances, it would be helpful to provide more guidance

"Could display a list of suggested instances from join.lemmy.ml"

Maybe Display:

• 5 Fastest Growing Instances
• 5 Most Active Instances
• 5 Instances recommended by the Instance owner

Might need a minimum number of members/activity level so going from 1 user to 2 users is not 100% growth and get you on the list.

[pscodes4fun]

Created a separate request for this at https://github.com/LemmyNet/lemmy/issues/1952

Do you have to federate all communities on an instance - maybe a setting like

• All Communities
• Whitelist - just federate these communities
• Blacklist - federate all communities except these

I suggest this because 2 instances may have an overlap of interests where it makes sense to federate communities relating to those interests. But there maybe communities on the other instance that are not compatible with yours or worse communities on your instance that may not be compatible with the other instance and will upset the other instance owner.

Rather then federating all the communities and having users banned by the other instance as a result - it might be smarter and create more cohesion to be able to select the communities that you will allow federation with.

[Nutomic]

@pscodes4fun Yes a whitelist/blacklist for specific communities would be interesting. Could you please open a separate issue?

About the suggested instances, that seems like something to implement after this issue is done, which will probably still take some time.

[Nutomic]

This could actually be implemented in an easier way: When first receiving activities from a new instance or attempting to fetch its objects, throw an error and queue a "federation application" for instance admins. This could work similar to the existing registration application feature. Only after that is confirmed can federation start between the instances. Essentially this would provide a way to use allowlist federation, but in a much simpler way as instances dont have to be allowed manually.