

There’s things built for entirely different reasons that can be used as a federated Wiki if you wish, like Fossil (a federated version control system with a Wiki)
https://www2.fossil-scm.org/home/doc/trunk/www/index.wiki
Note that Wiki federation has a whole bunch of potential issues if you try to allow automatic updates from arbitrary users. Wiki servers rely heavily on antispam measures which often require a lot of analysis of the user’s connection, data which often isn’t available over federation, so submissions by others have to be validated manually. Fossil being a version control system means it is more of a mirroring friendly Wiki than truly federated, but you can set it up so that mutually trusting mirrors can replicate each other’s validated commits/updates.










Wikis benefit more from the ability to mirror them and to link between them than they benefit from full federation. You need much better antispam on a popular wiki than in most other user content systems, and that’s not solvable with just blocklists like in many other federated systems. You need almost all antispam working server side, the user side fixes doesn’t work effectively.
It would be useful with atproto (bluesky) style portable identity where you could log into other wiki hosts from your own hosts user account to submit stuff (allowing you to maintain a single account in federation through OAuth logins, while still allowing each wiki to be centrally managed) with support for mirroring and native cross-linking between mutually trusting wiki hosts. You could replicate the Wikia/Stack Exchange user experience this way, without all the ads and without any central gatekeepers. (Very similar to stack exchange actually, as each individual Wiki would be read-only to you until you login to it separately (still using one a single account))
Things like content addressing could allow proper static links that survive page name changes for the cross-linking, etc.