Note I said lemmy AND the activitypub protocol, ie lemmy does not currently have this capability. If it were added to mainline lemmy I’d be open to configuring it, but its not so I can’t.
The root cause of the issue is well understood, the solution is available in lemmy already: multiple concurrent outgoing federation connections to remote instances. AZ has had this configured since it was available. LW have not yet enabled this, though they’re now running a version that has it available.
Appreciate the offer, but I’m not interested in customising the AZ server configuration more than it already is. If you write it up and submit a PR that the main lemmy devs incorporate, I’d be happy to look at it.
I’m not interested in customising the AZ server configuration more than it already is
There would be no customization of Lemmy itself. You’d only have to add a sidecar service.
If you don’t want to do it, fine, no one can force you to. But then perhaps it would be nice to be transparent with your users and tell them that the delay in federation can be avoided.
You’re contradicting yourself there. By definition adding an external service is a customization to lemmy. I’m not interested in running un-vetted software from a third party.
This has been discussed previously with a request from a reputable source to batching content from LW. That setup required an additional server for AZ, close to LW. And for LW to send their outgoing federation traffic for AZ to it, which then batched and send to the real AZ server. This offer was declined, though appreciated.
I’ve been transparent and open about the situation. You seem to think this is the fault of AZ, and we’re willfully not taking an action that we should be taking. This is not the case.
As it stands the issue is inherent with single threaded lemmy federation, which is why the devs added the option for multiple concurrent threads. Until LW enable this feature, we’ll see delayed content from them when their activity volume is greater than what can be federated with a single thread. To imply this is the fault of the receiving instances is disingenuous at best, and deliberately misleading at worst.
You won’t be making any changes to Lemmy source code itself, that’s what I mean. I wouldn’t count adding something that is independent from the service as “customizing it”, but if that is what you meant, fine.
That setup required an additional server for AZ
What I had in mind would be to run the relay myself, and you would only have to set up/manage an extra service that could run along your Lemmy process.
You seem to think (…) we’re willfully not taking an action that we should be taking.
Well, yes? You have the possibility to take the initiative and mitigate an issue that is affecting your users, and you can solve the problem independently of the third-party’s cooperation. Why put yourself at the mercy of others when you have enough power and agency?
With the resources available its not feasible for AZ to develop/deploy custom solutions that can be resolved by remote instances with trivial configuration changes.
I’m not going to address specific parts of your post, suffice to say I disagree on almost everything you said.
As I said previously, if you have a workable solution please do devlop it and submit a PR to the lemmy devs. I’d be happy to try your suggestion should they roll it in.
Setting up parallel sending also would require more resources on their part.
It is your problem to fix, yet you are only willing to take action if the solution comes in the form that is most convenient to you. I genuinely don’t understand why, but I guess it’s between you and the users on your instance.
Note I said lemmy AND the activitypub protocol, ie lemmy does not currently have this capability. If it were added to mainline lemmy I’d be open to configuring it, but its not so I can’t.
The root cause of the issue is well understood, the solution is available in lemmy already: multiple concurrent outgoing federation connections to remote instances. AZ has had this configured since it was available. LW have not yet enabled this, though they’re now running a version that has it available.
Appreciate the offer, but I’m not interested in customising the AZ server configuration more than it already is. If you write it up and submit a PR that the main lemmy devs incorporate, I’d be happy to look at it.
There would be no customization of Lemmy itself. You’d only have to add a sidecar service.
If you don’t want to do it, fine, no one can force you to. But then perhaps it would be nice to be transparent with your users and tell them that the delay in federation can be avoided.
You’re contradicting yourself there. By definition adding an external service is a customization to lemmy. I’m not interested in running un-vetted software from a third party.
This has been discussed previously with a request from a reputable source to batching content from LW. That setup required an additional server for AZ, close to LW. And for LW to send their outgoing federation traffic for AZ to it, which then batched and send to the real AZ server. This offer was declined, though appreciated.
I’ve been transparent and open about the situation. You seem to think this is the fault of AZ, and we’re willfully not taking an action that we should be taking. This is not the case.
As it stands the issue is inherent with single threaded lemmy federation, which is why the devs added the option for multiple concurrent threads. Until LW enable this feature, we’ll see delayed content from them when their activity volume is greater than what can be federated with a single thread. To imply this is the fault of the receiving instances is disingenuous at best, and deliberately misleading at worst.
You won’t be making any changes to Lemmy source code itself, that’s what I mean. I wouldn’t count adding something that is independent from the service as “customizing it”, but if that is what you meant, fine.
What I had in mind would be to run the relay myself, and you would only have to set up/manage an extra service that could run along your Lemmy process.
Well, yes? You have the possibility to take the initiative and mitigate an issue that is affecting your users, and you can solve the problem independently of the third-party’s cooperation. Why put yourself at the mercy of others when you have enough power and agency?
With the resources available its not feasible for AZ to develop/deploy custom solutions that can be resolved by remote instances with trivial configuration changes.
I’m not going to address specific parts of your post, suffice to say I disagree on almost everything you said.
As I said previously, if you have a workable solution please do devlop it and submit a PR to the lemmy devs. I’d be happy to try your suggestion should they roll it in.
Setting up parallel sending also would require more resources on their part.
It is your problem to fix, yet you are only willing to take action if the solution comes in the form that is most convenient to you. I genuinely don’t understand why, but I guess it’s between you and the users on your instance.
You’re wrong, I’ll leave it at that. Won’t be replying any further.