stratself

yeah, it’s consuming. I believe a big part of this is due to Matrix’s HTTP sync-polling being more expensive than simply maintaining a TCP stream (which is what XMPP does)

In fact, since XMPP syncs in the background so well, I use Conversations as a UnifiedPush backend for Matrix. You can find another article here as well

Since this is a selfhosting sub can you actually explain how you’re hosting it?

Hi, ntfy/another unified push backend is the third party

Android notifications are notoriously difficult to get right. May I ask how is Nextcloud Talk currently implementing notifications? Is it through ntfy, a background service, or Google’s Firebase? Have you allowed background usage for both the push app and the chat app?

I use Matrix with Continuwuity and Element X, and it’s doable most of the time except for small bugs. If you disable federation, the resource usage should be minimal too. But it also requires a third party for push service which can be unreliable.

On the XMPP side, there is also Snikket which you could look into. It offers both a server (running modified Prosody) and a mobile client (modified Conversations). XMPP can run as an efficient background service on Android, so it’ll receive in-band notifications.

Regardless of options, one of the main problem I’m aware of is that Android variants tend to overkill various background app, leading to missed notifications. I think it’s better to debug on that aspect as well

I don’t think geoblocking would be a great fit for Matrix, since you’d be contacted by servers from all over the world. It’s more suitable for something like a static website

There are various technical alternatives (ActivityPub-based stuff like PixelFed/Loops/Mastodon/GotoSocial/Sharkey/Akkoma/something else on the Fediverse)

But would you take the plunge of self-discovering different content, which might as well be none of your topics of interests? Would you be acquainted of vastly different UI/UX such as the lack of recommendations, and the technicality of federation? And lastly, will you find it a place with communities to socialize and content to enjoy from in the long run?

I think trying out on a public instance would be a good way to answer those questions. PixelFed most closely resembles Insta, but the other ones can do too. Then you can consider selfhosting your own

How on earth do you have 54 release candidates, each of them adding significant feature, and not bumping your versions? Wouldn’t it be nicer to just put them on the main branch and cut a semver release every now and then? At least that’ll save on the frequency of posts here

When you say “on each device” you mean this configuration would refer to the services running on that device right? Not that every client device needs to have this set up?

The device that runs multiple services will set that up, yes. Not the client.

All my web services use apache or lighttd. Do I use caddy just for this or do I have to figure out how to move each of them to use this web server?

Apache and lighttpd can both do the same thing that Caddy does (multiplex many services via subdomain names on port 80). Caddy is just simpler and hence recommended.

You can move all services to use Caddy, takes some learning but overall better. Alternatively, if you already set up apache/lighttpd for each of your services, you can put Caddy in front and do something like

http://service1.devicename.lan/ {
    tls off
    reverse_proxy localhost:<port-that-apache-listens-on>
}

Also does it work for non-web services, like ssh or samba? (Which wasn’t in my original question, I only thought of it now.)

No. Also, those should be running on their dedicated ports anyways

Use Caddy on each device, with tls turned off. Basically

http://service1.devicename.lan/ {
    tls off
    reverse_proxy localhost:8000
}
http://service2.devicename.lan/ {
    tls off
    reverse_proxy localhost:8096
}

I use my own “solution”: github.com/stratself/tswg

Run tailscale ping if it’s using a DERP relay that means you’d get abysmal speed and bandwidth. Usually this is because the NAT can’t be punched through. Try opening proper ports and/or configure a peer relay

I custom-build the Caddy container since it is easy to do with xcaddy. It is automated to run every week via Forgejo Actions on a Forgejo repo, and one can pull the latest images from there using Portainer or whatever docker updater software there is.

You can also use any other CI/CD solutions you like as long as it churn out a regularly updated image. Github Actions is another good one if you don’t wanna set up Forgejo.

The caddy-cloudflare image is probably also enough for your use case, assuming they’re regularly updated and has no vulnerabilities. But if you like control, CI is one way to go.

Use the –resolve flag e.g. curl --resolve matrix.example.com:8008:127.0.0.1 https://matrix.example.com:8008/

Why is there two nginx containers? Can you do nginx1 --> continuwuity?

Does continuwuity show any logs? What about nginx? Check Element Web’s devtools, does the 499’d network request say anything of note?

Maybe have a chat in the support room

If you are running a conduit fork, what is your reason for leaving conduit, and if you are running conduit, why didn’t you switch?

Conduwuit (predecessor of Continuwuity and Tuwunel) hard-forked fron Conduit and introduced breaking database changes. That is a significant people don’t easily “switch over”

It may be slow in development, taking a bit longer to implement a new feature, but not too much longer.

I would say its pace of development is very slow compared to the pace of Matrix in general. But if you only want the barebones features, you can use it.

Or am I missing something the others have to offer?

Feature-wise, Continuwuity offers email support, single-use registration token, policy server integration, user suspending, a ton more of admin commands, and some extra endpoints for Element Call. It is also actively working on OIDC-OAuth (so you can login with your IDP), and an ecosystem-wide Admin API. It also has an active community. I can’t speak for the other fork.

Lastly, I don’t think anyone “hate” conduit, the project is alright. It’s just not the topmost option.

As to answer your questions, threaded conversations are mostly a client issue. The UX for them are still not very good so not a lot of people use it.

SSO/Auth is actually quite hard to support. There’s the “legacy SSO” option which is deprecated in favor of native OIDC, and afaict only Synapse supports it for now. But Continuwuity is activeltly working on it.

Taildrop if you use Tailscale.

<offtopic> It’d be nice if there’s a Syncthing built into Tailscale or some of the mesh VPN solutions. Taildrop is good but it’s not entire directory sync with proper conflict resolution.

Surely I can use Syncthing inside Tailscale but 1. I have to depend on their public discoservers, or 2. I have to host and configure the discoserv myself for every client which is tedious to do </offtopic>

I’m running continuwuity, and ejabberd as text-only IM servers to talk to some communities. The latter (and XMPP in general) has more moving parts (more ports, SRV records, etc) to set up, but messages deliver much faster and take much less resources. They’d probably both run fine on a VPS with the proper tweaks anyhow - the Rust-based server makes Matrix actually not suck after all

For bridges, I’ve used maunium-discord as a Matrix bridge in the past, and trying out slidcord right now. I think Matrix bridges still got better UI/UX due to more supported features (spaces/threads) and coherent clients, though let it be known Slidge is a hobbyist project. If your chat server is mainly for bridges, stick to Matrix and consider disabling federation. Also Matrix if you’d like your friends to switch over from Discord - it has more Discordesque features like custom emojis/stickers and SFU-backed group calls

Though this doesn’t mean I’m unrecommending XMPP. I do appreciate its clients’ snappiness, in-band notifications, and unrivaled efficiency. I kinda wanna write a blogpost comparing both software and protocols, but right now I don’t have an opinion about one over the other. They’re both cool albeit they both leak different metadata differently

YOU WILL NEED TO UPDATE AGAIN!

There is another vulnerability making the rounds with details pending embargo. Please update to the latest version (again)

• continuwuity: v0.5.1
• tuwunel: v1.4.9
• conduit: v0.10.11
• grapevine: commit 0aae932

• DNS adjustments aren’t needed if you do .well-known delegations which is easier
• Can recommend continuwuity, it runs much better on less resources. Lacks certain features compared to Synapse but overall good
• Notifications (and read markers) depend on client-specific black magic to work
• Federation do sometimes silent-fail completely, you can reset continuwuity’s cache when that happens. But full room history convergence needs patience
• Don’t join large rooms unless your server can handle the load
• Don’t host public rooms without modbots

The many small bugs make Matrix still bad - I wouldn’t recommend a non-tech user unless accompanied by a 24/7 admin. It is trying to improve but very slow because of reasons

Should’ve specifically asked the operators/hosters if they need a better answer. But this has more engagement so