Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)S
Posts
4
Comments
116
Joined
12 mo. ago

  • 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. As in: it doesn't just go between you and your server

  • 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, a million client frontends, 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
    }
    
      
  • 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. But if you like control, CI is one way to go.

  • Hi, I do think this is a very cool idea. I appreciate using the WebRTC stack, and see that there are even AR/VR integrated too. I do have some questions about this project:

    • How do you see groups to be implemented (if that's on your roadmap)? IIRC webrtc mesh topology doesn't scale really well with many nodes, and how does a group handle netsplits between participants when some are offline?
    • Will you address offline delivery of messages, and how? Afaict, maybe something like a P2P relay with limited retention can help, although it must be in semitrusted/trusted territory
    • Do you see any chance this technology may be used in alternative networks (TOR, I2P, etc)? I guess that deviates from the webRTC model by a lot, but could there be any technical developments for it to become a possibility?

    Thanks in advance for any responses :)

  • 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 from 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 actively working on it.

  • Support for delegation to an external IDP (without MAS) is a work-in-progress

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

  • Selfhosted @lemmy.world

    Technitium DNS v15.1.0 released with OpenID Connect integration

    github.com /TechnitiumSoftware/DnsServer/
  • Selfhosted @lemmy.world

    Technitium DNS v14 is released with support for clustering

    github.com /TechnitiumSoftware/DnsServer
  • Selfhosted @lemmy.world

    Made an alternative to Tailscale + Gluetun

  • Selfhosted @lemmy.world

    Looking for lightweight homelab dashboard that can run as nonroot container and also supports OIDC