• 0 Posts
  • 21 Comments
Joined 1 year ago
cake
Cake day: August 21st, 2025

help-circle

  • I do this albeit with Tailscale. Netbird/Tailscale would act as a node of your VPN and you can configure reverse proxy routes (via tailscale serve or Netbird’s equivalent) from the VPS edge to the homelab. You can even do SNI passthrough and have TLS terminated at your home, if you want, though this can be a bit slower

    Alternatively you can even expose stuff via their servers. Tailscale Inc calls this service Funnels, and Netbird should have similar offerings. It’s kinda like Tunnels but you gotta use their domains, so a VPS acts greater as a dedicated entrypoint.

    Lastly yes you’d be exposing the service to the general public internet, so some basic security is needed. Netbird has a Crowdsec module integration, might wanna look at that one and set up rules/detections. Consider putting extra auth in front of Jellyfin, use Authelia or something with an auth screen. And only expose the stuff you need, not your internal dashboard or whatever admin UI.


  • 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


  • The case of free CI/CD, visibility, and network effects are already said. So I wanna offer an anectode: someone I know is a graphic designer, who maintains a project that curate icons. Moving to Codeberg means he has to interact with PRs using the CLI, which he really does not have familiarity with. GitHub OTOH has a simple desktop client that allows natively switching across PRs, approving then in the UI, etc. It’s really, really convenient for someone who’s not a developer.

    I think Forgejo-based platforms will need to work on a very good GUI client, in order to attract less technical contributors.




  • I wanna reshare my experiences here. Essentially it doesn’t scale well with large rooms, and isn’t friendly with janky/underpowered equipment like XMPP. But with a lot of performance tuning it can go a long way.

    For a room, the amount of servers you federate with is a more reliable metric than member count (so 5000 accounts on 2 servers would likely take less load than 500 accounts on 500 servers, as an example). There are some large public rooms that are very broken, and I advise banning them before users get to join



  • stratself@lemdro.idtoSelfhosted@lemmy.world•Matrix hosting
    link
    fedilink
    English
    arrow-up
    1
    ·
    9 months ago

    The easy solution is to choose someone other than matrix.org, get everyone over there, and hope it works out in the long run

    The technical answer is that if you own your domain name you can migrate from a managed solution to a selfhosted one with some caveats. If you can’t migrate the database, then some data will be lost (namely, unfederated rooms and local-only data) and your friends will likely need to do a few things (reset their passwords, and export/reimport their encryption keys). Unfortunately there are no database migrator between different server software right now


  • stratself@lemdro.idtoSelfhosted@lemmy.world•Matrix hosting
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    9 months ago

    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


  • 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


  • 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.




  • 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.


  • stratself@lemdro.idtoSelfhosted@lemmy.world•Geo-distributed Jellyfin
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    9 months ago

    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 :)