XMPP Service Operators - 2024-08-19

> xmpp-client jabber.de. 5222 > Priority: 0 Weight: 5 > IP: 2001:4ba0:ffa4:628:: > Test: [Not OK] > tls: failed to verify certificate: x509: certificate has expired or is not yet valid: current time 2024-08-19T06:00:40Z is after 2024-08-18T21:30:48Z > IP: 213.202.254.140 > Test: [Not OK] > tls: failed to verify certificate: x509: certificate has expired or is not yet valid: current time 2024-08-19T06:00:40Z is after 2024-08-18T21:30:48Z Does anyone have contact to jabber.de people?

devilz?

jabber.de? Not again please. I have some contacts there, and they constantly tell me, that this open source xmpp thing is not working, and we should switch to something more reliable.

The solution is to migrate them to an own server where one can ensure the avaibility oneself; centralized services prevent picking a less reliable server than other users of the same service and it's easier for the users that don't need to understand anything

Especially if they don't cost anything. That's not a solid business plan for an open server

I'm considering switching to eiabberd for clustering ability

Prosody is pretty cool and lean but it doesn't have clustering or even the ability to fail over to another server

If someone knows a way to make prosody fail over, even if it's a degraded state please let me know

There are a few strategies, but ultimately if you want full support for that stuff, then certainly it's a reason to consider ejabberd

Are these documented?

Not really, maybe some posts on the mailing list

It boils down to "only run a single node per host at a time, keep storage synchronized" and there are numerous ways to achieve those things depending on your requirements and preferences

e.g. whether you consider having a shared RDBMS as the storage a solution

> MattJ: > 2024-08-19 11:40 (CDT) > It boils down to "only run a single node per host at a time, keep storage synchronized" and there are numerous ways to achieve those things depending on your requirements and preferences Are those ways documented and is there a way to have prosody running 24/7 as a backup with read-only storage?

Read-only storage is impractical for almost every use case. Assuming you want MAM and offline message support, you wouldn't be able to send/receive messages while the primary was down

Yes

No mam or msg storage is better than no service at all

Last login time won't be updated, neither will the audit log

There's an audit log?

mod_audit

https://modules.prosody.im/mod_audit

do any of the servers support syncing member list across multiple rooms?

ukko, surprisingly I don't know of anything supporting that (though it's possible something does and I am just not aware). I think it would be a handy feature for a number of use cases. Of course it does overlap with the "spaces" thing, which there is some interest in working on in the near future, so maybe it will become more commonly available that way.

thanks

is spaces being pushed forward by any grant or just going as is?

No grants related to it that I'm aware of