jdev - 2023-07-11

17:28:38 lovetox> but i now think its safer to make it a occupant-id / room-jid tuple it's always safer to do so, you could be dealing with malicious MUC servers trying to trick you.

always scope IDs to the issuer.

👍️

Hello guys, do you know if it's possible to run 2 servers ejabberd. One in my house and one in a vps. That's for me to be able to send message through the same jid when i'm home and internet is down.

If yes. Do you have any url that explain.

In theory ejabberd supports clustering, but as I understand it you need a reliable low latency connection between servers so that still wouldn't work for what you want

I run my XMPP server at home and have a backup LTE connection instead, maybe that could work for you?

You want a High Availabilty cluster, but most things instead do Load Balancing types of clustering. From what I've understood, doing both kinds of clustering at the same time is Very Hard.

It's something workable. But how does it works for bigger ejabberd setup ? One with world wide users ?

You could also try asking in xmpp:ejabberd@conference.process-one.net?join

Does ejabberd clustering recover cleanly from prolonged network unavailability? If so, doing something with DNS SRV priorities might work, but meh. Is it worth considering this to be an infrastructure problem instead, and arrange for a hot-standby site to take over when the primary side becomes unavailable?

Myeah, some sort of standby and use some sort of database wide-area clustering to sync the data, is the approach I would go for. Should work with any XMPP server even.

If 'home' is disconnected from the internet, is there a high dependency on retaining XMPP connectivity in the first place? Your client will still connect, but none of the remote-domain XMPP entities will be reachable.

You'll basically be able to interact with people that are physically in the same house - assuming standard instant-messaging functionality.

Yup but my home is big

or is this to keep available resources on your server to the outside world (in which case this has merit)

It actually span several house

Shouting instead of IM'ing isn't an option? ;)

And i ha e a preference to keep things local if possible

Sharing a link or call is better by IM

Sure, there are plenty of reasons to want this. I'm happy for anyone weighing the cost/benefit different than me.

> That's for me to be able to send message through the same jid when i'm home and internet is down. If that's the use case then just running one at home is enough no?

as an aside: for audio/video, it might be sufficient to run STUN/TURN server locally, and have your XMPP server outside, to have decent performance.

If your internet is down and you are at home everything still works

Shouldn't need STUN/TURN _inside_ your local network I would hope

Zash: if the XMPP connection flows over NATs to the outside world, and clients are isolated in the LAN, maybe?

but yeah, that's stretching things

unless _conferencing_ maybe, but at this point, I'm mostly trying to invent problems...

TURN doesn't help with conferencing

So having 2 servers with 2 account is easy. Just not transparent for users

No, you'd have to run something more elaborate.

You could also have two separate servers with separate domains and use s2s to talk between them

If you prefer to run things locally for privacy reasons, then having two domains, like Zash suggest, might be preferable to keeping a remote hot-standby site up-to-date: you'd still be pumping all of your data online, which kind of negates the privacy reason for using a local server.

Laura: I'm unclear why you don't just run a server at home which is usable from anywhere when your home internet connection works, and from home when it doesn't?

My connection is not really reliable. It shut once every 2 weeks

I need to be present to restart the box

Laura: I solved that problem by connecting one of these to my server: https://pikvm.org/

My internet provider's box is shit. I need to protect it with ups. Because every time electricity cut for less than a second it goes into half state not on nor off

Thanks for the link

biboumi replies to a disco info on the irc server with

<identity type="irc" name="IRC server irc.libera.chat over Biboumi" category="conference" />

and on a channel

<identity type="irc" name="#asterisk on irc.libera.chat" category="conference" />

how can a client know that the first one is not a groupchat

and the second one is

No @ means muc service rather than muc

It's the only way to tell per current specs

some people run MUCs on the same domain as user accounts.

singpolyma, there is a third level with gateways, #foo%bar@baz, bar@baz and baz.

ok i think i remember now, its a gap in the spec

and there is no way to see the difference

really sad :/ so much good UX out of the window

lovetox: just beat up everybody who runs a channel on a domain JID and you're done

I really wish spec did not say much service should advertise it supports muc protocol. Or be required to exist at all really ✏

IMO channel on domain jid is a spec violation. I don't like that this is true, but it seems to be

not seeing what that has to do with it Ge0rG

if someone wants to run a channel on the domain, thats fine by me, he should just be able to say so in his disco info

infact there is no way to communicate that a address is in fact a groupchat, which is mind boggling how this could go unnoticed into the spec

lovetox: well, category=conference is meant for both in https://xmpp.org/registrar/disco-categories.html

in retrospect, <identity category='component' type='conference'/> would've been great

> if someone wants to run a channel on the domain, thats fine by me, he should just be able to say so in his disco info Except the MUC xep says this is not allowed. And also there is no way to say this in disco info ↺

singpolyma: I've been in rooms that were hosted directly on a domain component

I'm not even sure if 0045 actually forbids that

Ge0rG: yes, doesn't prevent it being a xep violation

> Each room is identified as a "room JID" <room@service> (e.g., <jdev@conference.jabber.org>), where "room" is the name of the room and "service" is the hostname at which the multi-user chat service is running.

🤔

This is a silly restriction FWIW

0045 requires that a MUC have a muc id which is the localpart and a service which is the domain part

Yup

About as silly as mandating that e.g. HTTP Upload be on a subdomain.

Silly, but present and currently necessary

does not help with bridges

as room@service on a bridge is as demonstrated, not a groupchat

> As explicitly stated in RFC 6122, both the Room ID (node) and Room Nickname (resource) portions of an Occupant JID MUST be of non-zero length.

> About as silly as mandating that e.g. HTTP Upload be on a subdomain. Wait what ↺

lovetox: well, IRC.libera.chat@whatever should not have a conference identity of muc var since it is neither a room nor a service

moparisthebest, not an explicit spec thing, but certain client(s?) require it

but nothing hinders biboumi to simply add a second identity with "component" or?

but it's also not explicitly stated anywhere that you can have http upload on the domain itself, all the examples show a subdomain, and we all know only examples count :)

singpolyma, yes its a service

its the IRC console

> moparisthebest, not an explicit spec thing, but certain client(s?) require it This is absolutely disgusting which ones do that? :P ↺

its the IRC server

lovetox: it can't be a MUC service because it's not a domain

That sounds literally harder to implement and for no reason at all

Per MUC xep

Siskin (unless fixed recently?) and Snikket-iOS at least

singpolyma, how does that help me?

im not saying it needs to be a MUC service

but its definitly not a groupchat

and i need to know that its not a groupchat

Is it advertising that it is? If so that's a bug in biboumi

or are you saying biboumi is wrong in adding the identity

Yes

yes i could follow that argument

```xml <iq from="muc.xmpp.org" type="result" id="SpNocoftZ_VfjYk0sLtB_2WT"> <query xmlns="http://jabber.org/protocol/disco#info"> <identity category="conference" name="XSF Chatrooms" type="text"/> ``` and ```xml <iq from="xsf@muc.xmpp.org" type="result" id="RlBWpuwcQQWD1lFK5JjzVT82"> <query xmlns="http://jabber.org/protocol/disco#info"> <identity category="conference" name="XSF Discussion" type="text"/> ``` ... ✏

what do you want us to see here?

Same identity on both here too?

its everywhere, its because the MUC XEPs demands it

as said, you cannot differenciate a service from a room, except you follow the argument that a domain cannot be a room

Yup. It's a bad thing in the xep imo but since it's there you have to filter out domain JIDs as not a channel.

Which is what I had to implement

yes i will do that

and add a bug report for biboumi, that it should remove the identity

or change it to something useful

Does biboumi also advertise muc feature on that jid?

I look for conference identity and muc feature both

(as in must have both and not be domain do be a muc I can join)

biboumi announces almost nothing

but on the room it has <feature var="muc_nonanonymous" />

thats not on the service

ah you mean the muc feature

yes its on both

I mean the muc protocol feature

Yeah

Is it on the weird third thing?

The IRC service

yes its on the irc service

yeah biboumi follows the logic that the irc service is a muc service

Heh, what does it say about user@service jids? :)

not implemented? pfft

Right, ok, so at least that must be removed IMO since it literally doesn't speak that protocol. Then you can argue about the conference identity as well

hm they disabled registration at their tracker

probably because of spam

biboumi moved to codeberg btw, same as poezio/*

Ah well it's poezio/biboumi, https://codeberg.org/poezio/biboumi

ok why is this not mentioned on the gitlab instance

Because it's recent

That should be done I agree

The GitLab is meant to go away any day now.

and is irc.jabberfr.org

not clearly a gateway to a non-xmpp service?

why does it not add a corresponding gateway identity

where can i report that again, is this also in biboumi code?

Yeah, I think so ✏

what exactly makes a service a MUC service?

to my knowledge there is no command or anything that interacts directly with the MUC domain?

singpolyma, you said prviously it clearly speaks not the MUC protocol

what makes you say that?

The IRC service ? It's neither a room nor a muc service so what muc protocol would it speak?

A MUC service is such because it to the domain of a MUC

ok issue created, lets wait 2 years ✏

> ok issue created, lets wait 2 years Lol :P

lovetox, could you also add that to the registrar?

I’d rather not add non-standard identities, and make sure every gateway is at the same page.

nicoco, how do you solve this issue?

he probably dont, the thing is with irc bridges which makes them unique

that they want you to interact with ircserver@gateway

It's just a bug, nothing unique here ;)

I remember old Gajim was using the leftmost label in the domain to determine which kind of component it was, but that was disgusting.

i would not care what ircserver@gateway announces at all

Link Mauve: even older gajim supported identity as well. Back before 1.0

if this thing would not send me 100 messages

goffi also, what do you do for AP domains?

Link Mauve: that is unlikely to have this bug since there are no MUCs involved

singpolyma, I wouldn’t consider that a bug, and there is no MUC here either as the IRC server’s JID will send you chat messages IIRC.

> I remember old Gajim was using the leftmost label in the domain to determine which kind of component it was, but that was disgusting. funny thing is that this works still better then looking at disco

Link Mauve: the bug is that it advertises it is a muc when it is not

Link Mauve: not sure what issue we're talking about but this is the disco info of slidge: https://git.sr.ht/~nicoco/slidge/tree/master/item/tests/test_shakespeare.py#L658 ✏

Link Mauve: I don't have the context and too busy to catch up or follow right now, but the AP gateway doesn't do MUC. It's pubsub and one to one messages.

singpolyma: let me know if slidge behaves in a bad way, one way or another, I'm happy to fix things :-)

I don't think slidge really has a place this bug would come up, but if I notice anything funky I have your number ;)