jdev - 2026-07-25

Why is it `<feature var="foo"/>` and not `<feature>foo</feature>`

In disco#info

Goot the ticklegoblin!, at this point, we can only guess.

using an attribute has the advantage that it is syntactically impossible to put anything in there except strings

(no child elements)

Empty elements are usually a design flaw but they were popular for awhile bpor whatever reason. OPML is a great example of that going too far heh. And sure disco info has some of that on it but it's not a problem enough to bother changing it imo

Ah, the <feature var='foo'/> rather than <feature>foo</feature> is a design trick because XMPP's subset of XML idiomatically avoids mixing text and element nodes, and so <feature>foo</feature> is harder to extend later. In this case, we never did, though.

The more interesting question is why it's <feature var='foo'/> rather than <foo xmlns='urn:xmpp:foo'/>, really.

this would be more code to parse

really we want a list of things here, so <feature> is fine for me, and namespaces are usually put in attributes

and we mostly put a namespace into the var ✏

This is extremely nitpicky, but I found XEP-0085 chatstates tags awkward to parse as opposed to having it just <chatstates xmlns='' type='foo' /> But really it's fineeeeee

for replies in whispers (re https://xmpp.org/extensions/xep-0461.html#business-id ) am i meant to use origin-id/id or stanza-id? i would figure stanza-id would be present, and im pretty sure ive seen cheogram or monocles reply to messages in the main chat in a whisper, but gajim does not accept this (perhaps it wants origin-id/id)

yes, i feel that, its easier to call getTagAttr(chatstate, type) and analyse the value, than, looking for a child that can have 5 different names ✏

jjj333_p (any pronouns), the text could not be more clear

it tells you exactly what you should do for type=groupchat, and tells you exactly what you must do for all other types

a PM is type=chat

oh right thats fair

[necessary comma after 'no']

lovetox, jjj333_p (any pronouns): um no, because currently deployed MUCs will forward messages with type=normal and others too so be sure to handle them all appropriately (unlike, say, dino) ✏

heres what i ended up landing on (from https://github.com/jjj333-p/twitterbot-xmpp/blob/8c1cbe41745c9f8c900d35c317f04f3daef6d844/main.py#L186 ) ```python3 replyto_jid = msg['from'].bare if \ (msg['from'].bare in self.rooms and msg['type'] == "groupchat") or \ (msg['from'].bare not in self.rooms and msg['type'] == "chat") \ else msg['from'] origin_id = msg.get('origin_id', {}).get('id') replyto_id = msg.get('stanza_id', {}).get('id', '') if msg['type'] == 'groupchat' else ( origin_id if origin_id else msg['id'] ) ```

protip: if you hate someone in a MUC just PM them the IQ to ask software version and if they are using dino you can spam them with message type=normal and jingle calls and they will have no way to block you or even know/report who is spamming them

(im making a pretty simple bot, i just wanted it to be able to reply to the specific command that triggered it)

I reported it privately nearly a year ago so meh

the lesson is assume everything that can happen will happen and don't silently/automatically respond to anything even if technically the RFC says responding to IQs is a MUST

you must be able to at least gracefully fail when things arent compliant

> the lesson is assume everything that can happen will happen and don't silently/automatically respond to anything even if technically the RFC says responding to IQs is a MUST As usual you jump from a real problem to an inappropriate suggestion ↺

> (im making a pretty simple bot, i just wanted it to be able to reply to the specific command that triggered it) (ultimately if the worst thing that happens is you have a reply that wont resolve or you send a message weirdly and never get a response its probably fine) ↺

type=normal isn't even different from type=chat in any way that matters for this I'm not sure what you're on about with that one

my interpretation is mopar was saying dino doesnt correctly handle messages of type=normal

the suggestion was because it's no business of a stranger like a muc participant what software you are running or how far away you are

also the fact that gajim displays = as - is screwing with my head rn

> the suggestion was because it's no business of a stranger like a muc participant what software you are running or how far away you are That has nothing to do with replying or not. It has to do with what you reply with ↺

dino in particular displays type=normal like a 1:1 message with the MUC JID, meaning you can't tell what nick is spamming you

That's a bug though. Not a problem with type=normal

correct , I didn't say otherwise

> also the fact that gajim displays = as - is screwing with my head rn That may be your font choice, it looks fine for me ↺

but automatically/silently replying to stranger's IQs can't possibly help you and can hurt you so no reason to do that either

> That may be your font choice, it looks fine for me maybe. im using noto serif, however no other app does this ↺

even an error can reveal rough distance and eat your battery

i mean its still relative to your server

yep, but probably other things too

i wouldnt worry about it until clients begin proxying media by default

that's it though , the rule that makes sense for security is never reply automatically/silently *by default* then if it makes sense for some specific thing where you've carefully considered the consequences, do it there only

eh

I agree. It just so happens that for iq we've already considered the consequences 🙂