Natanael

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.

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.

Depends on the federation model. For lemmy I assume things like comments aren’t pushed automatically (?) until the thread is opened, but in some models the instances pull all new content from at least the known accounts / spaces from known servers (I think regular Mastodon does that)

You can start with timed bans, so they get the point

deleted by creator

Probably reverse proxy too if it’s really unstable

Wireguard is most reliable in terms of security. For censorship resistance, it’s all about tunneling it in a way that looks indistinguishable from normal traffic

Domain or IP doesn’t make much of a difference. If somebody can block one they can block the other. The trick is not getting flagged. Domain does make it easier to administer though with stuff like dyndns, but then you also need to make sure eSNI is available (especially if it’s on hosting) and that you’re using encrypted DNS lookups

Your workaround is precisely why I said “more practical”. Any updates to your tooling might break it because it’s not an expected usecase

You don’t want FIDO2 security tokens for that, use an OpenPGP applet (works with some Yubikeys and with many programmable smartcards). Much more practical for authenticating a server.

BTW we have a lot of cryptography experts in www.reddit.com/r/crypto (yes I know, I’m trying to get the community moved, I’ve been moderating it for a decade and it’s a slow process)

Client software (browsers, etc) would need to resolve it, just like mailto:

It certainly should happen, but it’s not likely because it takes too much momentum

You need to set up a publicly accessible device (in this case the VPS) as your IPv6 gateway

So you set up your VPN connecting your network to the VPS (should probably be set up from the router) and set your router to advertise an IP adress for the VPS which is routable from your local network as the gateway address (and should probably also run DHCPv6 for your network)

(note, I have not set up this stuff myself so I can’t help with implementation details)

So by default your instance respect mod removals.

You can change that as a server admin, so comments would remain visible to other users on your instance.

I think your instance is authoritative for content of comments, but the community hosting instance is authoritative for which comments are approved (other instances respect such removals by default)

Somebody should consider building a fork that works of bluesky’s content addressing scheme, that way communities can effectively be re-homed in full even if the server dies

Lemmy stores your posts and replies on both your host server and on the server of the community.

One interesting behavior to note here that is different from reddit is that while comments on reddit belong to the profile of the person commenting and is then imported to view in the subreddit (this is why you can edit comments after being banned, and why there visible in your profile even if removed from a subreddit), on lemmy the target community is instead authoritative and your host server will by default respect a deletion by community mods on different servers by also removing that comment from your profile.

Clients should convert automatically (unless the user doesn’t want it to)

Yeah, but who would be able to prove it?

Instance admins could easily patch it in for their local communities (just add a filter ignoring API actions like posting and voting for some users), but it’s not official and probably won’t ever be official behavior

Bluesky does strict content addressing with hashes plus post ID (unique per repository, this allows edits). So you can choose which version to refer to. If you need to archive or mirror stuff you can use the hash, and threads can have both methods so you can see which version of a comment somebody replied to, etc.

Without content addressing that’s almost impossible

A lot of this doesn’t work easily on the activitypub model, because accounts and posts and communities live on their host instances, and every interaction has to be relayed to them and updates have to be retrieved from them.

While you can set up mirrors with arbitrary additional moderation that can be seen from everywhere, you can’t support submission of content from instances blocked by the host instance.

The bluesky model with content addressing can create that experience by allowing the creation of “roaming” communities where posts and comments can be collected by multiple hosts who each can apply their own filtering. Since posts are signed and comment trees use hashes of the parent you can’t manipulate others’ posts undetected.

Bluesky already has 3rd party moderation label services and 3rd party feed generators for its Twitter-like service, and a fork replicating a forum model could have 3rd party forum views and 3rd party moderation applied similarly.