XMPP Server - Prosody

[LoudLemur]

Prosody would help integrate with Peertube too: the Peertube livechat plugin uses Prosody:

[djxx]

@girish - any update? I see you guys shipped 8.0, congrats! I'm looking at moving servers again and no XMPP is a deal breaker for me at the moment.

[LoudLemur]

@djxx said in XMPP Server - Prosody:

@girish Any update on this? I'd like to be able to keep tinkering on this before I forget all the prosody and cloudron stuff I crammed in my head

I know the feeling! We lose a lot if we suspend focus on a project for a while.

[girish]

@djxx Is https://github.com/DerekJarvis/cloudron-prosody still the latest code? We should have some free cycles coming up, so I thought we can take a look if this is something easily doable. I can't promise we will publish it since it seems quite complicated (it's why we had to remove Jitsi too, it became way too hard to fight their system). Was the cert issue the blocker for you to just use your custom image yourself?

[jdaviescoates]

@girish it's possible that Snikket might be simpler to package:

https://github.com/snikket-im/snikket-selfhosted

[djxx]

I was actually looking into Snikket again last night. Back when I did my first packaging of XMPP, Snikket was still a bit too limited in features. I'll take another look at Snikket, but I suspect it will have the same cert requirements as part of the XMPP protocol.

And @girish , I don't remember perfectly, but based on my notes above the cert was the only thing I couldn't work around in the app package approach. While checking out Snikket I'll confirm if it also needs it.

[djxx]

Research done - it is indeed a limitation of XMPP. from https://snikket.org/faq/:

[djxx]

The way both Snikket and Cloudron apps work, it would "technically" be a different domain to allow your XMPP usernames to be like: user@domain.com , instead of the uglier user@chat.domain.com . The SRV records are trivial, and the real limitation as far as Cloudron is concerned is the app getting the cert with the TLD.

I guess there may be other apps in the future that would need the primary cert in order to verify trust between the TLD and the app itself - so perhaps this could be a new app option?

Also, Snikket intends to be a "one and done" installation, and it packages its own TURN/STUN server. For that reason, I think it's not ideal to use as the XMPP solution since it will make the app heaver than it needs to be, and require more ports.

[LoudLemur]

I had AI look at this, but it wasn't very fruitful. It suggests using Cloudron's wildcards and, for Prosody, using its ACME plugin which can obtain certificates:"Let's dive into the specific technical challenges and potential solutions for using Prosody on Cloudron:

1. Domain Flexibility with Prosody:
   Prosody is indeed more flexible than Snikket in this regard. You can configure Prosody to use different domains for XMPP addresses and the web portal. The key configuration options you'd need to focus on are:

VirtualHost "example.com"
  -- XMPP domain configuration

http_host = "chat.example.com"
  -- Web interface domain

This separation isn't possible with Snikket's current setup.

2. Certificate Handling:
   The core issue here is obtaining a certificate for example.com when your Cloudron app is hosted at chat.example.com. Prosody itself doesn't solve this, but there are potential workarounds:

a) Use Cloudron's wildcard certificate: If Cloudron provides a wildcard cert for *.example.com, you could use this for both the chat subdomain and the main domain.

b) Manual certificate injection: You could manually obtain a certificate for example.com and inject it into the Prosody container. This would require modifying the Cloudron app to allow for custom certificate paths:

ssl = {
    certificate = "/path/to/custom/fullchain.pem";
    key = "/path/to/custom/privkey.pem";
}

c) ACME plugin: Prosody has an ACME plugin that can obtain certificates. You'd need to ensure the Cloudron app has the necessary permissions to write these certificates and that the DNS challenge is used instead of HTTP:

plugin_paths = { "/usr/lib/prosody/modules" }
modules_enabled = {
    "acme"
}
acme = {
    provider = "letsencrypt",
    challenge = "dns-01"
}

3. SRV Records:
   Cloudron should allow you to set custom DNS records. You'd need to add:

_xmpp-client._tcp.example.com. IN SRV 0 5 5222 chat.example.com.
_xmpp-server._tcp.example.com. IN SRV 0 5 5269 chat.example.com.

4. Cloudron Integration:
   The existing GitHub repo is a start, but you'd need to modify it to:

• Allow for custom domain configuration
• Implement one of the certificate solutions mentioned above
• Possibly add a script to automatically update SRV records via Cloudron's API

5. Reducing Overhead:
   Unlike Snikket, Prosody doesn't include a TURN/STUN server by default. You could either:
   a) Use an external TURN/STUN service
   b) Implement a lightweight TURN/STUN server as a separate Cloudron app

To move forward:

1. Fork the existing Cloudron-Prosody repo and start implementing these changes.
2. Engage with Cloudron's development team about adding an option for apps to use the primary domain certificate. This would solve many of these issues at the platform level.
3. Consider implementing a custom module for Prosody that interfaces with Cloudron's API for dynamic configuration and certificate management.

This approach should address the specific technical challenges you're facing with implementing an XMPP server on Cloudron while taking advantage of Prosody's flexibility. The key will be integrating Prosody's configurability with Cloudron's app structure and API."

[djxx]

@girish - Given that the only blocker (that I know of so far) is the TLD certificate availability, would it be a decent workaround to package this entire thing as an application, and then run a one-time command to symlink the TLD certificate into the application directory? This would allow the sys admin to choose which application deserves access to the TLD certificate, ensure the app always has access to the latest certificate, and work around the current limitation of apps not being able to request the TLD cert.