jdev - 2021-07-15

Re-posting for a broader audience: is carbons more closely related to message forwarding or history sync? Trying to decide where I would group a message carbons package (because I think the name "carbons" is confusing and makes me think the feature is for sending one message to multiple people), but I'm not sure if it belongs in the "forwarding" package, the "history" package, or somewhere else entirely maybe grouped with one of those two things or maybe on its own?

Maybe the concept (and the package) is "delivery" and includes anything related to message delivery options (delay, forwarding, carbons, maybe others)

hello what's the recommended way for a MUC to redirect a user to another MUC?

i heard about gone and see-other-host, but does any have better client support?

southerntofu: probably by sending a mediated invite and then kicking the user: https://xmpp.org/extensions/xep-0045.html#invite-mediated

wut

That seems.. ugly

For users already in the muc that is. For new joins I think there's a disco field specifically for showing them the new one instead, but I can't remember what it is

Sam, sooooo the client wouldn't connect automatically to the new addres sright?

ah that sounds better :)

Yah sorry, I was thinking earlier in the process and realized what you meant after.

I forget where it's defined; just a second and I'll look

Or maybe I'm imagining it, I thought ejabberd had this option anyways

prosody uses <gone/> after a room has been destroyed with a redirect jid

but do clients respect it in practice?

Nevermind, the thing I thought exited doesn't. At least, not in the config form for the room I thought I'd seen it in.

my use-case would be automatically redirecting the user to a specific gateway when the server detects a foreign protocol used on the requested remote service, and knows of a gateway to reach it

eg. /join #foo@libera.chat would redirect me to #foo%libera.chat@biboumi.MYSERVER or something like that

:w 36

(you may treat me as a heretic, i've already received the treatment on IRC-side :P)

So I've tried to argue that non-stable addresses is meh, already, but they don't want to hear it :P

Maybe somebody can help my case

(or their case, maybe I'm just wrong about that)

Hi, I'm new to XMPP. Is the "resource" column in the JID protocol already deprecated? I am developing a XMPP chatbot which bridges messages to other IM. I want to use resource to identify the user of my service so that I can just create one account for the bot. But I don't see different when I send message to the same account with different resource provided, like user@chat.linchpins.cloud and user@chat.linchpins.cloud/test

wancat: hi! Welcome to XMPP 🙂

The part before the @ identifies the user, the part after the / (the resource) identifies a single session of the user

The resource is certainly not deprecated (at the protocol level), but most people now have multiple devices and they want to receive the same messages on all of them

Also note that sessions (resources) come and go, e.g. as users switch between devices

For a bridge to another network you'll typically want to connect to the server as a "component"

It's a special connection type that allows you to control traffic for a whole domain (usually a subdomain)

If your bridge connects as foo.example.com, it will receive (and can send) messages to/from user@foo.example.com and user2@foo.example.com, etc.

Basically faking as many JIDs as you want, without needing to create a load of accounts on the server

southerntofu, fun idea. I don’t think any client supports <gone/> on MUC join and I think <redirect/> neither

but maybe you can get them to :)

(fwiw, <see-other-host/> is a stream error, you are looking for stanza errors)

southerntofu, I think I mentioned it but Link Mauve had a similar "problem" for his XMPP<->AP on prosody

MattJ: Thanks for your replies! Very helpful

> MattJ wrote: > The resource is certainly not deprecated (at the protocol level), but most people now have multiple devices and they want to receive the same messages on all of them How would you send a message to all resources then? Just by not specifying the resource?

Yeah, the recommended approach these days is to send to the bare JID (no resource)

But even if you send directly to a resource (which is still most clients today), it will get copied to all sessions that opt-in via XEP-0280 (carbons)

XMPP was one of the first messaging protocols to support multiple concurrent devices, we thought we were so smart... magically routing the messages to the right device. Then everyone went mobile, bandwidth became cheap, and everyone wants everything everywhere :)

tbh, I am not sure if it was smart to *not* fan out per default from the very beginning

but, 1. you specificy, 2. you code, 3. you use, goto 1

Well, fanning out was allowed by the spec in the bare JID case. Resource locking was probably encouraged by notification issues, and a desire to not have half a conversation on other devices.

The fix for half a conversation would require copying outgoing messages also, which is quite a leap

Hi everyone. Hoping to learn some things hopefully quickly. Glad I found this group.

I'm writing some simple C programs based on libstrophe. I'm trying to accomplish 3 things: direct message a recipient (done), discover/join available rooms (no clue) and send/receive messages while in a room (see previous task). To test this, I installed ejabberd on my server and have two users with one group set up. I have user_a connected using pidgin/tkabber. user_b needs to connect via my c program. I ordered the definitive guide to XMPP book, but it arrives tomorrow. Does anyone have any initial thoughts on my task?

That's how you join a room protocol-wise: https://xmpp.org/extensions/xep-0045.html#enter I don't know libstrophe at all though

And welcome :)

Is "service discovery" what I should be researching as far as finding out who is online and what rooms are available?

My cursory understanding is I just craft a bunch of stanzas that conform to these different xep-### extensions and that's how I get the info I need. Is that correct?

* I found it in section 6.3 of the link you sent (thank you)