We are (like everyone) on matrix.org now but realize we need to move eventually.

Consider moving to another open registration server too. Find one that supports Element Call

do I need to pay for a domain still?

If you’re gonna selfhost, you should purchase a domain for proper federation with the wider network. IP-only servers are possible, but they are generally banned in most rooms due to antispam. Same with dynamic DNS domains

Unless it really is easy enough to do it on a synology nas for text/voice/screen share…

You’ll need to integrate a Matrix homeserver (I recommend Continuwuity.org, much lighter than Synapse) and Livekit (the software that handle Element Calls). It’s not particularly easy so maybe consider managed hosting beforehand, too

I’m using Continuwuity.org (also a Rust-based server and forked from the same former project as Tuwunel) so I’ll name a few that this one lacks:

• Synapse Admin UI (helps a lot in large server setups)
• Ability to purge rooms and some history (Rust servers use rocksdb with high compaction, so not a high priority for them)
• Matrix Authentication Service (aka next-gen OIDC-based authn)
• Ability to become a notary server (maintain other servers’ signing keys for faster retrieval by the public)
• More niceties implemented for Element Call
• More niceties implemented for encryption

I don’t think anything except for maybe OIDC would be really needed for a small-scale homeserver, but they do lack them. For me the resource efficiency, storage savings, and ease of maintenance is definitely a larger factor in choosing the server implementation

You can try Snikket.org, which is basically Prosody but easier. But you can’t selfhost “on each person’s own computers” as you said because you’d still need a publicly exposable IP addresses and high uptime. Maybe you could try registering on an XMPP or Matrix instance you like and migrate your community over there first

Question for others: is Prosody’s (and XMPP’s) group calls really good? I’m under the impression that Matrix (with Element Call) is currently better due to the SFU architecture, but I’d be happy to be proven otherwise. I’m interested to hear required specs, how large the calls can be, and how much strain it puts on the TURN server and clients especially when it comes to multiparty streaming

AFAIK the Movim people are working on SFU calls too, but not soon

• E2EE: all servers support it
• Federation: this is where most of the resource hog is. If you disable it you can use anything. I enable it and use continuwuity.
• Voice calls/screen shares: requires extra integration with Element Call + Livekit
• Mobile notifs: requires integrating with ntfy or some other UnifiedPush service. Or download Element X from Play Store and use Google’s push services

Edit: the main differences between these servers are that Synapse is written in Python/Twisted and is known to take up huge storage space. Meanwhile all other mentioned projects are Rust based, has a shared lineage, are usually more efficient with storage and ops, though are more focused on a smaller user size and doesn’t yet have advanced Synapse features

If you want a non-federating LAN-only Matrix server, then STUN/TURN can be behind the NAT. Since you have Tailscale, STUN/TURN can also expose itself on the Tailscale VPN too. Just configure proper DNS records per-interface and you should be fine.

Since calls are p2p, the purpose of STUN is to determine a client’s (usually public) IP address, and TURN is to relay the connection if they can’t connect directly (i.e. behind NAT). If your clients are on the same LAN/VPN with unrestrictive firewalls then you might not even need any STUN/TURN altogether.

Few of the answers given were concrete. So here’s my take.

I am able to run singleuser Continuwuity on a 8GB RAM Pi machine with 4 cores, and join many large rooms (around >=1000 users, although the number of homeservers in the room is a more suitable metric). It would use around 2GB RAM, but you can tune it for less (basically reduce cache values, but ask in the room for more advice).

After a few months the database hovers at around 2GB, because the database uses zstd compression by default. It’s not anyhow a major problem like Synapse, just don’t use HDD for storage and you should be fine.

For best experience, I also selfhost a dedicated caching resolver (unbound) for continuwuity. That takes like a few hundred more MBs of memory.

Given the fact you’d like to play around with it, a mid-tier VM/VPS (2CPU, 2GB RAM, 20GB SSD) is a reasonable starting choice. For a non-federating server, it can take a lot less resource than this.

jade-liveit-guide.continuwuity.pages.dev/calls

the call docs are being rewritten to reflect latest developments. Join the Matrix room for further help too, it’s quite active these days

If you’re still interested in selfhosting a Rust-based homeserver, https://continuwuity.org/ will get you there. However if you’re just migrating your community to this federated protocol, making a room on an open registration server could be enough

Question: what sort of misconfiguration was it? Might have an effect on the round robin assignments of Cloudflare

Edit: just FYI, if behind a VPN, you may prefer using the DNS servers of that VPN provider to blend in with others. But I guess your VPN is your VPS so it’s a bit different here

Why are files unusable outside of Nextcloud? Consider using the External Storage plugin.

Imo there are two types of file servers: smart clouds with offline and smart selective on-demand sync on brand-specific clients, groupware support, conflict resolution, and enterprisy plugins (Nextcloud, Opencloud, Seafile, etc); and dumb clouds with protocol-based file transfers and filesystem-tree/userperms instant compliance (copyparty, sftpgo, etc)

Of the first one, only Opencloud has a native-looking filesystem (PosixFS) and does it without dependency on a db. It supports smart sync for Windows (via the same API OneDrive uses). Linux smart sync is sadly nonexistent due to lack of protocols, and whatever other software do (e.g. using an .owncloud placeholder file) is highly experimental.

Of the second type, you’d get all the standardizations and speed but no bidirectional sync nor offlineness - again this is honestly an advanced undertaking requiring academic understanding of distributed systems and whatnot. On Linux you may try emulating some aspects of it via a half-smart client like rclone with VFS, but the UX to store files offline is still not there.

Knowing these constraints I’d tier my storage into 2 parts: the daily files like notes and recent photos stored in one of the smart sync solution, ready for download and later offline use; and anything unnecessary (Jellyfin media, archives, ) to be in a dumb SMB share/SFTP mount.

HI, kinda late to the party. I’m in a similar rut with intercontinental internet issues, and would like to share my thoughts

While not a full-fledged CDN, you may consider setting up an Asian VPS to serve as a second reverse proxy/ingress route, terminate TLS there, and route plaintext HTTP back to your homelab (this virtual tunnel shall be behind a WireGuard VPN interface). As I’ve figured out in my blogpost here (see scenario 2), this allows the initial TCP and TLS handshakes to happen nearer to the user instead of going all the way to Europe and back home.

You can consider setting up a separate Jellyfin instance for Asia, but of course that comes with setting up syncing media, maintaining separate user credentials, and so on. So before renting compute, I suggest trying these smaller actions first - if they work you mightn’t need a VPS anymore:

• Look into Linux sysctls tuning of network parameters. My personal tweaks for the /etc/sysctl.conf stuff are:
  • Increasing all the memory usage for network stuff (net.core.(rmem_max/wmem_max/rmem_default/wmem_default), net.ipv4.tcp_(mem,rmem,wmem)`. Relevant blogpost and another. YMMV
  • Enable BBR (net.ipv4.tcp_congestion_control=bbr), a modern congestion control algo suitable for long distance/high latency.
• Implement some sort of Smart Queue Management on your router (e.g. CAKE algorithm) to avoid the bufferbloat problem
• Enable HTTP/3+QUIC on your reverse proxy for reduced handshakes. Though it’s unlikely native Jellyfin clients also benefit from such features

Curious to see if any of this helps :)

If it’s a bunch of users sharing a bunch of resources from behind a bunch of different VPNs, I guess the most simple way is to tell them to expose it to the internet

Are you sharing your Linux PC with a bunch of different users? Or are you sharing your Linux server with a bunch of different users?

The Cloudflare Matrix blog in the newswire section is an AI slopfest, featuring a vibe-coded repo lacking fundamental protocol features, trivially false claims about Matrix projects, and misinformed comparisons to market their software offerings. Its original version did not even disclaim any AI assistance, and dishonestly advertise the thing as production-ready. It is not anything of proper substance.

To the selfh.st maintainers, I urge you to include the community’s responses towards this action, for completeness of the situation

• Jade’s blogpost - https://tech.lgbt/@JadedBlueEyes/115967791152135761
• https://news.ycombinator.com/item?id=46781516 - Hacker News thread of above

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, the general ephemerality of its chats, 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

It’s basically XMPP with a clear packaging, from server to client

Yes.

If you want to access your NPM stuff on both Tailscale and LAN, either:

• Advertise a subnet route for your LAN range, configure Tailscale devices to use it, and use your LAN IP on the AGH rewrite, or
• Split Horizon: Have your DNS respond with a Tailnet IP when it’s queried from the Tailnet range, and respond with a LAN IP when queried from LAN. AGH cannot do this, but other software like Technitium can

Do a DNS rewrite at AGH, but instead of the LAN IP make it the Tailscale IP of your NPM machine. Then configure AGH’s IP address as one of the global nameservers on your Tailscale admin panel

Delete all A/AAAA records on Cloudflare, only use it for registrar purposes and the occassional certs authentication.

In your Tailscale DNS panel, disable “Use with exit node” option for your nameservers.

When turned on, that option actually allows you to talk directly to nameservers without tunneling DNS queries through the exit node. Since Quad9 in fact has a worldwide CDN, this would leak your (general) DNS query location.

I believe Tailscale send the queries in parallel and fetch the faster response, which is Quad9 in this case. Ideally for your use case, all your queries should be able to reach and show up in Pi-hole’s logs. Use tailscale dns commands for further debugging

Glad to know you got it working.

When you use a VPN as a matter of privacy, I believe you should use their DNS service too to blend in with the crowd. Because of DNS leaks, websites would likely know which DNS server you’re querying from, so using a selfhosted one instead of a VPN’s can be a major uniqueness vector. On the contrary however, I’ve seen many do exactly that, so I guess it’s not as big of an issue. So it’s your choice ultimately.

Now, if you opt for commercial VPN’s DNS servers, be aware that don’t usually block any ads (if they do it’s likely a paid option), and you’d want to configure your own local zones too. To intercept DNS queries and forward only the approved ones to the VPN, I think you have 2 options:

• Host Technitium on the VPN’d machine (your computer) and set up blocklists there. Create Conditional Forwarding zones: 1 towards the main TDNS server for your local domains, and the rest towards the 10.2.0.1 server for your public queries. Technitium may be overkill, AdGuard Home can also do this.
• Configure your main TDNS server to forward queries via the VPN tunnel. This requires the VPN tunnel having an available SOCKS5/HTTP proxy, to be used with TDNS’ Proxy and Forwarders options. Even better, you may use the Advanced Forwarding app to only use this routing for the VPN’d device, and use another routing for other devices