У меня ссылка из первого поста темы не открывается.

I am unable to open the link from the start post of this topic.

localhost(2026-07-19|14:57:51) ~/rust$ rustup update stable
info: syncing channel updates for stable-x86_64-unknown-linux-gnu
info: latest update on 2026-07-16 for version 1.97.1 (8bab26f4f 2026-07-14)
info: removing previous version of component cargo
info: removing previous version of component clippy
info: removing previous version of component rust-docs
info: removing previous version of component rust-std
info: removing previous version of component rustc
info: removing previous version of component rustfmt
info: downloading 6 components
        cargo installed                       10.63 MiB
       clippy installed                        4.71 MiB
    rust-docs installed                       22.73 MiB
     rust-std installed                       28.71 MiB
        rustc installed                       77.30 MiB
      rustfmt installed                        2.06 MiB                                                                                                      
  stable-x86_64-unknown-linux-gnu updated - rustc 1.97.1 (8bab26f4f 2026-07-14) (from rustc 1.96.0 (ac68faa20 2026-05-25))

info: checking for self-update (current version: 1.29.0)
localhost(2026-07-19|15:01:20) ~/rust$

I think that it should do backups first and remove only in the end. Or do parallel installs.

What you had read? Do you have a library? Do you have skills for thinking? May be you can start from applying them for yourself?

is not recommended for production systems

I think that this is because the protocol doesn’t contain means of routing (similar to “SEEN-BY” fields). But that is solvable with some coding. And current implementation will work in restricted (controlled) tree-like topologies. I think this is negotiable, and there are no too much nodes, so agreements are possible.

The main repository of this project is https://github.com/igniterealtime/Openfire License: Apache-2
Current version is v5.1.0 (2026-06-03)
The feature was implemented since v4.6.0 (2020-10-16)
«[OF-2030] - Add support for XEP-0289: Federated MUC for Constrained Environments»

An additional problem - the site https://lemmyverse.link/ is available only partially (requires VPN to work).

So my new idea is to deploy
https://github.com/RikudouSage/lemmyverse.link
into my website locally, and give 2 links - the relative (via local redirector) and the direct one (as a fallback).

the relative link on forein server will became broken, until they also install such redirector into the same path.

After that the link will always lead to local server and redirect to preferred server of user.

Проверяем:
https://лемми.опенсорс.рус/post/15

The existence of local replica doesn’t prove, that searching by remote URL will work (with remote server down).

You can also paste that into the search of any lemmy instance to find it, if they mirrored it

Yes, this works. But I don’t understand how. The question is - will it work, if remote instance went down?

«Your original url is right there in the path if it were to go down» But how it’s supposed to help one, to see the original URL? It will help only if the content is archived in some way. If remote lemmy server will go down. Then content will became unavailable, even If I install a local copy of that redirecting engine.

it give the resulting link as https://lemmyverse.link/xn--e1aghfa.xn--e1aqbccjfc.xn--p1acf/post/15 so the lemmyverse.link website is the single point of failure. It goes against the idea of federation.

deleted by creator