XSF Discussion - 2024-06-18

Daniel, did you give that "roster extension XEP" idea some more thoughts?

Is it explicitly defined that when an implementation breaks a (RFC 2119) MUST or MUST NOT condition, that a (suitable) error is to be generated?

(as opposed to make some kind of best-effort attempt at processing the stanza, maybe)

While writing tests, I'm wondering if I should assert that a particular IQ request yields an error response, when the request does not meet a specified MUST (such as a missing attribute value), if the XEP doesn't explicitly state what the expected outcome is.

From the offender's side, if you break a MUST then the consequences are (usually) undefined

On the receiving side, I'd recomment returning an error if possible

So, writing an interop test that checks for a(ny) error is not ... quite right (unless the XEP explicitly specifies that an error is to be returned).

negative tests for interop are generally tricky

... I've found that positive tests are not always as straight-forward either, but that's another matter...

but it's perhaps best to stay away from those negative tests, thanks.

Could you write a double-negative test? A server accepts a stanza that it shouldn't, etc? Rather than assert on an error, assert that you don't get the positive response that you would have gotten if the missing property had been provided?

Fishbowler: that still has the same problem, I think. As the specifications do not dictate what to do, it might be permissible to either return an error, or a non-error response.

Something something strict mode? 🤷‍♂️

nicoco: re https://xmpp.org/extensions/inbox/notification-filter.html do you have a prototype anywhere? do you plan to?

singpolyma, not yet, my plan was to try and get pinning + notif settings in gajim by submitting a MR. The tricky part is that you want to put 1:1 chats in bookmarks but the idea does not seem popular (?). Hence my pinging Daniel about a "roster extension XEP", something he mentioned here, precisely about that use-case. I'd love to have some sort of "full state sync" of gajim instances on different devices, including workspaces obviously, these are steps in this direction (I know that pinning and notif settings are not exactly what workspaces are about, but still, they are bricks in this direction). ✏

Just implementing for muc would be a good start. Not sure what "on mention" means for 1:1 anyway ... Maybe it means "on attention"?

Current draft mentions "always" but doesn't define it

The client type idea is interesting too. I wonder if the protocol's idea of type will map to something users want vs just doing per-client settings

sure, on-mention does not make a lot of sense for direct chats, but… we have no mechanism for direct chats anyway 🙂

I wonder if we could do a more generic all/important/mute type filter and then it's up to client and context what is important (mention, reply, attention, etc)

Always is a bit underspecified, and I can see why advanced clients might want to add "on-all-reactions", "on-reactions-to-my-messages", "on-replies" etc., but I tried to use the common denominator. The clients I know well (Conversations, Gajim, Beagle and Dino) basically already implement (non-synced) notif settings this way. I'm in dino right now and it's called "on" (always) / "off" (never) / "only when mentioned" (on-mention) 😉 ✏

Sure but I'm just talking about renaming on-mention to something more generally applicable like "important"