You don’t have to be on the NAS’ physical network to run some tests, if you can SSH into it, that’s enough to run some speed tests and latency tests to reference servers (e.g. Google, netflix, …), while doing the same from your PC simultaneously. Whenever you encounter “instabilities” you should be able to see which side of the connection is struggling more than usual. You should also be able to monitor the NAS itself for excessive IO or CPU using something like htop (even though that would be rather extraordinary if all that’s going on with it at that time is a Borg backup).

On the topic of Kopia, you can go the easy route of setting up a SFTP remote pointing to your NAS. All you need is SSH access to the NAS (so your current tailscale/borg set-up qualifies as is) and a folder where the SSH user can write. You can then compare backup times vs. Borg (in my use case, going from 18-25min with Borg down to 3-5min with Kopia). If you then want to try the HTTP repository server, there is a container for that, but the set-up is a bit annoying (the password to decrypt the repo needs to be stored on the NAS, you need to generate a SSL certificate pair and have the client whitelist the sha256sum of it, etc). Personally I haven’t found a substantial advantage to having the http repository server but YMMV.

Tailscale being merely a wrapper around Wireguard, which is pretty close to optimally efficient, I don’t think there’s much of an improvement to be expected by rolling your own or hopping over your VPS. You should probably start with investigating what’s causing the tailscale connection instability (is it your ISP? Is it the network on the side of the NAS?). If you are not bound to Borg, perhaps you can give a shot at Kopia, I found it to be much more performant for my use-cases, and it has a http “repository server” which you might be able to use with less protocols overhead than through your current setup.

Some might call it overkill or old fashioned, but my LaTeX CV versioned in mercurial as branches and hard linked clones has worked wonders for me for decades, now.

I figured that swimming and rock climbing do wonders to improve posture and back pain

Or plain old CalDAV

It’s there on the readme: https://hacdias.com/2026/07/28/filebrowser/

The project needs a rewrite from scratch, but the author had enough.

How does that compare to wallabag? (Does it?)

If you want notes “sometimes on the web, sometimes local first”, and possibly more than just notes (with the tools to extend into an actual knowledge base), you might be better served by https://triliumnotes.org/

I’m holding off on Fluxer until they decide how they’re going to implement federation

Seems wise. They seem competent in the front-end/client space and complete amateurs in the (difficult) protocol space. There is no example of successful tech (that I know of) that successfully added federation/P2P after the fact. It’s not an afterthought, it probably won’t ever happen.

Don’t do Element, Matrix is a nightmare (and a significant commitment) to self host. Other servers (recently, continuwuity) are a bit better on that front, but then you run into compatibility issues and edge cases as a forever second-tier citizen.

My advice is to just go with XMPP and ejabberd, and you will find clients for all kinds of usages and people (a free-er WhatsApp takes you to Conversations/Quicksy/Cheogram/Monocles/Monal, a better banquet/IRC-style rooms takes you to gajim/fluux, social networking and group calling takes you to Movim, etc).

Personally my needs are covered by Monocles on Android, Gajim on the PC, and Movim on occasions. Using multiple clients around the same protocol and account is a strength, not a weakness.

To add to the collection of chat apps enabling that, there is XMPP, too: https://f-droid.org/en/packages/de.monocles.chat/

I don’t think you know what a web app is.

I don’t think YOU do? A web app is an app built with web technologies and running in a browser. Which is also the case of Discord desktop (an electron app, i.e. Chrome).

Really? So I can message EA users with my MOVIM account? No? Well there’s a problem…

Again, you don’t seem to understand very much how any of this works. It’s pretty much the equivalent of saying “your devices at home are not using the tcp/ip protocol because I can’t ping your smart tv from the internet”. Actually, they do, but whoever operates the router (the XMPP server in this analogy) chose to make it this way. And yes, there is another way: for most of its history, GTalk was letting you connect to their XMPP server with the client of your choice, and talk to anyone else on the XMPP network besides accounts on @gmail.com. Federation is a built-in capability of the protocol that server admins may enable or not.

You can’t just label arguments you don’t like or agree with as “bad faith”. I have no motivation to hate on XMPP or promote Fluxer, other than liking one and disliking the other.

This is the extent of your argumentation:

• “XMPP is terrible by comparison.” (unsubstantiated)
• “XMPP is terrible.” (unsubstantiated)
• “I’ve actually used it.” (irrelevant)
• “clients are ugly and dated” (unsubstantiated and subjective ; specific to clients not the protocol)
• (talking about flaws) 'They are numerous. Anyone who has used them knows." (unsubstantiated)

it’s pretty clear by now that if you had any ability to comment meaningfully on this, you would have done it by now.

And importantly, my posts are a criticism of Fluxer. All I’m saying is “if you believe that you have the chops to develop a good client for a chat system, and you want it to eventually be self-hostable and federated, save yourself many years of suffering and do it on top of XMPP. Or at least if you don’t, take a good dive through it and come on the other side with a good story as to why your system is so much better. Showing mastery of the problem space will be free advertisement”.

I am talking about XMPP being almost 3 decades old

This is not the win you think it is.

It is not the win YOU think it is. So far you haven’t been able to cite a single specific issue with the protocol or universal flaws with clients. Get to terms with it: you are spreading FUD. Or make a real, substantiated case that supports your point.

Movim doesn’t even have a client at all, its just a PWA, which is a really poor experience.

Can’t wait until you realise discord is essentially the same thing :-) . Yup, it’s a web app. Always has.

You just come across as someone who doesn’t know much about the subject.

I don’t, and I shouldn’t need to. Good software doesn’t require vast amounts of research, you just use it.

People are using WhatsApp by the billions, which is essentially a stripped-down XMPP running on an ancient fork of ejabberd (there are many other examples of widespread use of XMPP: it props up your android notifications, it runs the nintendo switch network, EA/Riot games in-app chats are clients for it, etc).
But, nobody ever said that you need to research XMPP to use it. Only to have a sensible and articulated commentary in good faith. Which once again you fail at doing.

Then it’s even worse: if the goal is this, why give up on almost 3 decades of expertise solving that very problem?

I have no idea what you’re talking about.

I am talking about XMPP being almost 3 decades old and having gained a TON of experience and clever protocol design in the process. XMPP survived multiple generations of messaging apps (ICQ, AIM, Yahoo, MSN, Skype, GTalk, …)

In the way of usability. XMPP is actually a hodgepodge of different protocols sewn together and inconsistent across apps and servers.

Don’t believe all the disinformation you read online. XMPP is a IETF standard. It is extensible, and that’s the pragmatic take: in a federated environment, you can’t impose clients and servers to run identical versions, and so the protocol is versioned and contain fallbacks for all the major features. To help implementers cut through legacy extensions, there are compatibility suites that are revisited every few years or so. You will see that, the minute Fluxer goes self-hosted and federated (if ever), this clever extensibility will be dearly missed (we saw enough of that already with Matrix).

Moreover, XMPP has multiple independent client AND servers implementations, written in distinct languages. This guarantees that no actor can single-handedly take-over the ecosystem (a big risk with Fluxer, and many alternatives), and creates a fertile ground for innovation.

Fluxer has many many features that XMPP does not offer. If you’re familiar with Discord, you already know what those are.

If that’s so obvious, perhaps you could cite some? Did you even look into recent movim versions?

You cornered yourself into precisely NOT being able to invoke existing client shortcomings.

Again, no idea what you’re talking about.

You drove the discussion towards criticisms of the protocol, which is not the same thing as how clients implement it. In other words, you can’t simply say “XMPP sucks because this unmaintained client is ugly”.

No, because as I’ve already explained, XMPP is terrible.

XMPP deserves some fair criticism (like anything else having reached the real world and a substantial user-base), but that’s not one. You just come across as someone who doesn’t know much about the subject.

Then it’s even worse: if the goal is this, why give up on almost 3 decades of expertise solving that very problem? It’s a very complex one, believe it or not, and you can be sure that Fluxer won’t eyeball it in one shot, especially since federation is admittedly an afterthought and not baked in the design.

XMPP is terrible by comparison

In which way, exactly? You cornered yourself into precisely NOT being able to invoke existing client shortcomings. Protocol-wise, you would be surprised to learn how ubiquitous XMPP is even today, and for very good and practical reasons.

In all seriousness, Fluxer should just have been another XMPP client, purposely built for discord refugees. It would have gotten ahead faster by not reinventing a complex wheel, offered from the get go those characteristics (self hosting and federation) that are far-away roadmap items, and probably gained goodwill and many users in the process.

Time will tell, of course, but the internet history is riddled with failed messengers which bit more they could chew, the odds are not in Fluxer’s favour for one.

Another centralised system. By that simple definition, it will eventually turn against its users, like discord (or worse). Run away (ideally towards federated systems, XMPP with Movim is decent, and improving fast in areas that seem to matter to discord users, with EU funds, Matrix is another one)

That’ll work until they create for themselves new competitors that are good enough at previous (normal) market prices. And you don’t need incredible high foundry tech for that, so it’s closing up on them eventually.

It’s not as dramatic as GP makes it, but Matrix had been at the prototyping stage and at figuring out its core protocol and state resolution algorithm for more than a decade now, it’s pretty ridiculous in itself.

Isn’t that the premise of the “$4 ubuntu over droplet deployment” option?

Instead of having Secluso-Deploy ssh into some cloud box and prep it up with the server-side software, why not have a container deployment option as well? I get that you want to ensure that the server is publicly reachable for the mobile clients to work on the go, but ultimately (and in all honesty) at this point, that should be a user concern/choice (those more advanced users may be peculiar about running behind tailscale, a home-VPN, a port-routing config, …).

Needless to say, most people here might find it easier to work with containers and build trust in the project by having it run in an isolated environment with limited permissions than blindly trusting that the code is what it says it is and not quietly running a botnet at digitalocean with their PII attached.

No it’s not, and part of that is the current legislative laissez-faire in the US that put its regulatory bodies on a hiatus. Under normal circumstances, this stuff should have been under much more scrutiny and regulations. I’m not saying that the state should control what LLMs do or who’s access to them, but they could very much tackle the deceptive marketing, environmental and societal impact, unsound financing, abnormal market consolidation, and mitigate the overall financial risk.