hmmm the move handler doesn't seem to work that extremely well?
anyway, i've moved over to @Claire
hmmm the move handler doesn't seem to work that extremely well?
anyway, i've moved over to @Claire
the followers synchronization mechanism i've been working on for months has been merged in the development version of Mastodon and in glitch-soc as well 🎉
and it appears to work!
i described it here: https://git.activitypub.dev/ActivityPubDev/Fediverse-Enhancement-Proposals/src/commit/e26ad239386523ea69d55984ae349a50e75f4468/feps/fep-8fcf1f0.md
racisme, islamophobie, pol fr
Par ailleurs, selon plusieurs observateurs, le CCIF a pour objectif de faire abroger les lois de 2004 sur les signes ostentatoires de religion à l’école et de 2010 sur la visibilité du visage dans l’espace public.
what about faire interdire les associations, groupes et partis politiques qui voudraient bien faire abroger le mariage pour tous aussi
racisme, islamophobie, pol fr
« plus de 80 enquêtes pour la haine en ligne de ceux qui, d’une façon ou d’une autre, ont expliqué que ce professeur l’avait bien cherché, ont été ouvertes »
mdr est-ce qu'il en est fait autant quand une personne trans ou une travailleuse du sexe meurt et qu'il y a des dizaines ou des centaines de commentaires de ce genre
#Mastodon 3.2.1 has finally released, with a fix to follow relationships not always being deleted when they should have
However, that fix is not retroactive, so a few months ago, I started writing a proposal for a mechanism to synchronize the following state across instances: https://github.com/tootsuite/mastodon/pull/14510
This is something that is actually pretty hard to do in a way that is correct, efficient and future-proof.
Today, I've been working on it again to incorporate feedback from other fediverse implementors.
I think I'm at a point where I will accept this solution isn't as generic and future-proof as it could, but clearly document the condition in which it does work, and allow people who'd break those conditions (I don't know of any, especially using Mastodon) to opt out of it.
As for providing a truly generic and future-proof solution, there seem to be ways to do it, but they're significantly more tricky to handle, and given the serious consequences of followers desynchronization, I'd like a solution to be adopted soon, even if it ends up being an interim one.
Hey, Mastodon moderators: when one of your users report a remote person, would knowing whether the report was forwarded be useful?
If so, could you explain why?
Fediverse admin PSA
In the end, we are not going to drop support for host-meta
but we are still making a few changes that may affect some instances:
1. drop support for XRD on the LLRD endpoint: in practice this doesn't seem to be an issue, but who knows
2. only fall-back to host-meta
if the webfinger query raises a 404, and not if it has any other status. So if you don't have a working redirection, check that you're not throwing a 401, 403, a 500 or anything else there
I'll try finding affected instances and contacting them, but please have a look if you're running an unusual config
Fediverse admin PSA
Attention to #Mastoadmins
We are considering dropping support for host-meta
and XRD support (inherited from GNU Social/OStatus) in next #Mastodon version, as the webfinger spec is enough and simpler.
As far as we know, no fediverse implementation relies solely on host-meta
or XRD, so that wouldn't be a big change.
That being said, some deployments do (partly because of a guide I wrote ages ago, in OStatus times) depend on host-meta
. That could be the case, for instance, if you installed Mastodon so that it is on social.domain.org but serving @foo@domain.org
. In this case, please check that https://domain.org/.well-known/webfinger
redirects to, or proxies, https://social.domain.org/.well-known/webfinger
.
With nginx, this could be done like this:
location /.well-known/webfinger {
return 301 https://social.example.org$request_uri;
}
i ended up merging it!
if you're a glitch-soc instance admin and you update, beware that for the time being, suspending a local user will not be immediately visible to other instances (it will only be visible when the account is actually deleted, which by default happens 30 days after suspension, unless you cancel that, or trigger the deletion earlier)