-
-
Notifications
You must be signed in to change notification settings - Fork 892
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Streamlined workflow to federate with new instances #1487
Comments
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:
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.
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 ) |
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.
Sorry I didnt mean that this step would be automated, should have clarified.
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. |
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. |
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):
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:
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 MurmurationsNetwork/MurmurationsProtocol#30 in their tracker) |
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:
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. |
Created a separate request for this at #1952 Do you have to federate all communities on an instance - maybe a setting like
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. |
@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. |
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. |
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.This issue replaces #862.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: