jdev - 2024-08-05

> XMPP doesn't really have a separate concept of a "conversation" Well, there is the thread identifier, but I'm not sure anyone really uses that. ↺

Cheogram uses that, and... Movim maybe?

Still, what is a "conversation"?

See XEP-0201?

(One I'd forgotten existed, I was typing a message saying that nobody knows what a conversation/thread is in semantic terms, but thought I really ought to check)

I'm currently working on stream renegociation in Jingle / WebRTC to allow the add/removal of new video/audio tracks.

https://blog.mozilla.org/webrtc/perfect-negotiation-in-webrtc/

I saw that it was specified in Jingle here https://xmpp.org/extensions/xep-0166.html#def-action-content-add But it seems that the latest WebRTC browser implementation are doing it directly without the 3rd party signalisation channel.

What are your tough on this ?

For some reason iqCaller (xmppjs) does not return anything and I have to handle everything through events (e.g. I create a trigger function which sends out a command to the server, then I just handle everything in the stanza event) is this intentional design or something I'm doing wrong?

`await client.iqCaller.set(query).catch(console.error);`

https://github.com/xmppjs/xmpp.js/tree/main/packages/iq#get looks to me as it should be returning something. They don't have the `.catch()` in the examples tho not sure if that would really change anything for successful responses.

Tho the way the .get and .set functions extract the response payload seems to assume that it will always match the request name+xmlns, but I'm not sure that is the case

seil, what is `query` you're trying with?

> seil, what is `query` you're trying with? ```js async function syncMessageList(lastMessageId: string) { console.log(lastMessageId); const query = xml( "query", { xmlns: "urn:xmpp:mam:2" }, xml( "x", { xmlns: "jabber:x:data", type: "submit" }, xml( "field", { var: "FORM_TYPE", type: "hidden" }, xml("value", {}, "urn:xmpp:mam:2") ), xml("field", { var: "after" }, xml("value", {}, lastMessageId)) ) ); await client.iqCaller.set(query).catch(console.error); } ``` ↺

Yeah MAM will not work with this code, is there no special MAM query in xmpp.js? ✏

> Yeah MAM will not work with this code, is there no special MAM query in xmpp.js? Not that I know of.. ↺

As I said, .get() and .set() make assumptions that will not always work, especially not with MAM where the results are delivered in message stanzas, not the iq-result

So would it be better to just make a .request()?

Yes, + something to catch <message><{urn:xmpp:mam:2}result/>

until you get the iq result

I also looked into iqCallee but I don't really understand what it should listen for (client.iqCallee.set("???", (ctx) => {...}))

If you're trying to do a lot of stuff like full MAM in JavaScript you may also be interested in snikket SDK, which wraps xmpp.js and adds a lot of high level features like a MAM sync stack and persistence layer

> I saw that it was specified in Jingle here https://xmpp.org/extensions/xep-0166.html#def-action-content-add But it seems that the latest WebRTC browser implementation are doing it directly without the 3rd party signalisation channel. edhelas: the link you sent is using a signalling channel. onnegotiationneeded you get the latest SDP and send it. With jingle instead of sending the SDP you want to figure out what changed (something added, removed, etc) and send the right event ↺

Yes that was my point, the problem is that Conversations is using the Jingle way but WebRTC moved to have a specific channel for that

Didn't checked how Dino and the others are doing it

I'm not sure what problem you mean?

In an already existing audio-call: When I enable the camera on Conversations I have a content-add in Jingle When I enable the camera on Firefox/Chrome they basically already negociate the thing using their signaling channel

They don't have a signalling channel

So I'm not sure what you mean