jdev - 2025-10-14

> No element can ever have "no namespace" in xmpp so is it just assumed to be jabber:client if theres no xmlns= atribute? ↺

seems weird to me that its parsing in data that isnt there in the regular xml. maybe if there was an xmpp_stanza_get_ns() i could see that but im surprised its on the atribute list

xmlns of an element is inherited from parent element

maybe im holding it wrong, but i expected this to be more just traversing the raw xml not trying to be both clever and making me iterate over a c array of c strings

i figured out my bug though, the compiler was getting clever and invoking the destructor of a class before i expected it to

something something oop is a mistake

i thought `stanza = xmpp_stanza_copy(s);` made a deep copy that i was supposed to invoke `xmpp_stanza_release(stanza);` on

https://downloadable.pain.agency/file_share/068ed986-e0f3-7e8c-95c1-99c79f564be8/5f188088-c645-449e-93fd-6c465ec99871.png

yeah to me that implies its my responsibility to release it

There's nothing "clever" about xmlns inheritance rules. Every compliant XML parser needs to implement that

> There's nothing "clever" about xmlns inheritance rules. Every compliant XML parser needs to implement that alright i see ↺

> i thought `stanza = xmpp_stanza_copy(s);` made a deep copy that i was supposed to invoke `xmpp_stanza_release(stanza);` on okay so im getting the child `body` element and making a copy, then immediately releasing the original stanza. is copy not a deep copy ↺

(also is there a libstrophe chat? if so that may be a better place for these questions)

profanity muc

huh alr

what is the situation with multiple devices in a muc, if one device changes the nickname, is this propagted to the other device somehow?

i have seen often that it then shows 2 resources in the MUC

It's propogated via bookmarks when desired/supported

So not by the MUC via presence

but i dont understand why, because on nick change we get a new presence with code 303, and 110

why would a MUC that supports multi session nicks not forwards this self presence to all resources

maybe you want 2 different nicks ? (is probably the reason if I had to guess... I doubt anyone actually wants 2 different nicks with the same avatar)

yeah, the premise was you might want to join with two nicks. In reality gc3 probably won't still support this because while it's nice at the data model level to be flexible, it hasn't been that useful in practise AFAIK

and as moparisthebest says we already have several things that mostly assume it doesn't work this way (avatars, occupant ids)