jdev - 2022-07-25

regarding 0045

> A MUC service MUST include the MUC extensions even if the client did not send an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace on entering the room; naturally, a client MUST ignore such information if it does not understand it (in accordance with RFC 6120).

this is from 17.3, rule 10.

what are MUC extensions in that context?

lovetox: that reads like GC1.0 join, which we luckily killed with fire a few years ago

i wanted to know what the words MUC Extensions mean in the context of a presence

it MUST include it

what is a MUC Extension

The extension is probably the <x xmlns='http://jabber.org/protocol/muc#user'> payload

so do i read this correctly, a service MUST add a x element with a MUC related namespace, in EVERY Presence it sends

I think this is only related to the immediate response to a join presence

ok so also in an error presence as a response to a join?

The previous wording was: > A MUC service MUST send extended presence to a client even if the client did not send an empty <x/> ele

Changed in 2011

0045 is not the best worded of XEPs, so maybe it makes sense to remove this point

how would that help ..

im trying to figure out if a MUC service must include <x xmlns='somemucnamespace#> in presences

lovetox: I don't see how it could make any sense, so removing it would make the XEP clearer?

lovetox: in which presences?

in all

well, occupant presences are supposed to have the <x> user element, which other presences are there?

error presence in response to a join, for example, banned, or password needed etc etc

how would an error presence with that <x> element look?

is it legitimate for a <presence> to contain both the <x> and an error? The examples imply such a thing

it is legitimate to send the content of the presence back as error

obviously if i join, i send <x> with it

but some impl dont do this

so the question is, if the xep intends that they should, if not mirror the initial presence, at least include the <x>

its weird to me from a spec point, that all presences include <x>, but not error presences

lovetox: original 0045 allowed joining a room with a presence that doesn't have <x>

groupchat 1.0, but we've removed that because you can't see if it's a presence update or a join from a desync client

from a development view, its really painful how often in xmpp we have to guess, or cache somewhere some data, to even determine what a stanza is about

Do you think that could have been avoided with foreknowledge, or is it a direct consequence of flexibility?

it's a consequence of bad protocol design, and by bad design I mean twenty years of moving forward the state of the art ;)

Carbons and MAM are pretty bad designs that only result from avoiding breaking changes

So yeah, could have been avoided with some precognition

Shame

qy: computers and IM were very different twenty years ago

Ofc

Im not lamenting it, i dont mind much, was just wondering why

XEP-0045 was an attempt to make IRC channels better

its just not consitently a first class citizen

there is type=groupchat, which is good, its clear what we deal with here

but yeah then there are messages which are not type=groupchat, but can still be from a groupchat

presences with <x mucnamespace>

but yeah also presences without it

lovetox: error presence is always a response to a presence you sent

if i would design a protocol, single chat and groupchat would be separated pretty hard in ALL aspects

Ge0rG, yes its stuff like this "yeah its a repsonse so the client probably can figure out itself whats this about"

or private messages which are of type chat ✏

thats for me in practice, it generates much development overhead

yeah thats my favorite, private dm type=chat

In theory that should be fixed with ... MIX where everything is type "groupchat" ... maybe ... sorta, If I did glance at 0369 correctly.

at least the message payloads

I get the impression MIX is in the realm of vaporware atm

More than vaporware, bloatware

it was supposed to simplify stuff but then someone decided it was good to add PubSub to it which extremely complicated stuff instead.

As usual in the best of XMPP traditions.

MattJ: can we place the new images in the wiki?

> but then someone decided it was good to add PubSub to it which extremely complicated stuff instead. Nah, PubSub was there from the beginning. MIX is "what if we used PubSub" taken as far as it goes, from the very first whiteboard drawings.

Source: I was there, 3000 years ago, when the courage of... I mean when the early design was drawn up at a Summit

What do people do if they unmarshal a bit-of-binary data element and the CID doesn't match the actual hash of the data? I guess when receiving it I can just return an error, but sending it is weird (I either let the user specify the CID in which case it might not match, or I don't but then the XML marshaler doesn't know what hash to use and I don't have a good way to tell it what hash to use

)

Sorry, very vague question. I suppose it should have been two different things: if the data doesn't match when receiving do you still use it (and cache it under and opaque string tied to that specific user instead of globally by hash) or do you discard it?

And "if I have struct{ Data []byte, MaxAge int }" or similar that marshals to a data element, how do you ensure that the output SID is correct?

Sam, you take its SHA-1.

Link Mauve: I don't understand how that relates to the question

I'd rephrase, but I can't tell what the ambiguity or confusion is

Sam, that was an answer to your last message only, if you have a Data []byte, you take its SHA-1, prepend cid: and append @bob.xmpp.org and you got the SID.

We have a few things where you know some kind of hash before you fetch the full thing. Caps, avatars, BOB e.g. Do any of those XEPs say anything about what to do in this case?

Err, I confused SID and CID, sorry.

Probably consider it a failure

When receiving invalid stuff I tend to reject it and propagate the error to the user so they can tell their contact to fix their thing.

For sending, you should aim at not sending anything invalid ever.

Link Mauve: you're saying "only support sha1?"

In that second question my confusion is that I have no good way to decide what hash to use if multiple are supported

Sam, yes, bob only supports SHA-1 IIRC.

It doesn’t do XEP-0300’s hash agility.

Same as avatars, same as 0115.

I don't think that's true

It mentions algo+hash, and I don't see anything that says "algo always == sha1"

Wanna bet how many clients will support anything but SHA-1, given it’s the only algo used in the examples? ^^'

Maybe I just shouldn't support BoB at all then and work on some new way to do this sort of thing; not having any sort of ability to upgrade seems like a pretty serious flaw

We do have a problem in general where nothing that uses hashes tells you where to get the canonical name of them and half these specs don't make it clear if you can actually use multiple hashes or not, I don't think it's just this one

> <Zash> Source: I was there, 3000 years ago, when the courage of... I mean when the early design was drawn up at a Summit 🧙‍♂️ that explains the beard

Sam, some specs have been updated for that ability, like 0115 → 0390.

Actually you seem to be right about hash agility in 0231, it seems to be properly supported, aside from the text form of the algorithm not being spelled out.

Oh great, this uses "sha1" and that uses "sha-1", I just realized that my general hash/names stuff is probably wrong for some specs

It uses "sha1" as the only example, I could guess sha256 and sha512, but beyond that would it be sha3-256? blake2b-512? With underscores? Undefined here.

IIRC the IANA hash database hasn't been updated since sha1 came out too (or something, I don't remember exactly when, just that it's only old hashes)

oh, no, it's got sha2 stuff at least. Still, not a lot here: https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml

and like https://xmpp.org/extensions/xep-0300.html it's different from the 'sha1' used in BoB

Anyways, without re-inventing the world I'm now even more stumped about how to implement this properly and my original two questions.

Maybe the answer to the first question is to ignore it; caching will be up to the user anyways so I can just hand them the CID and provide a function to verify it against some data to save them a few steps.

Time to snort up some Second Syndrome and write BoB 2!

Honestly, I can't tell if BoB is actually useful or not but if it is we should probably make it at least sort of consistent and less ambiguous

https://www.rfc-editor.org/rfc/rfc6920.html mapped to XMPP mayhaps?

huh, TIL they have multiple specs for URLs containing hashes.

Just like us!

That registry seems more complete at least

A-B all the specs

maybe we should start doing something like https://quicwg.org/quic-v2/draft-ietf-quic-v2.html to combat people supporting only what's in the examples

huh, that's an interesting idea, although I kind of can't imagine it would accomplish anything

oh wait, this named information registry doesn't have sha1 in it… so really both these iana registries are pretty useless.

I guess sha3 isn't really necessary yet, we could go with the one that has sha2 and sha1 names and try to get it updated later if necessary

I wonder if I should even parse this format. CID URls can be anything, and it is a "SHOULD" that they follow this particular format. Maybe I should just treat this as an opaque string.

That's one approach

Suggested fix: https://github.com/xsf/xeps/pull/1193

I’d recommend against adding sha-1 as supported though.

Current version says sha1, let’s keep it at it and not add newer unsupported names for the same thing.

That's for forward compatibility, but yah, I could go either way.

Note that it's only supported when reading, not writing so in theory it never gets used.

Also went ahead and submitted a suggestion in response to the form discussion the other day. https://github.com/xsf/xeps/pull/1194\

I don't think there was any consensus in the discussion, but it sounded like this was the original intent and it's easy for users who want to mix and match to create a new field type later.

Sam, don’t assume someone won’t mess it up, and then every implementation would be forced to add compatibility just for it.

If it’s downright forbidden, then nothing has to change.

if algo.toLower().startsWith("sha") && algo.endsWith("1") { SHA1 } what could possibly go wrong? :P

I'm not sure what you mean by that; that's part of the point, if they mess it up we can still read either

The obvious mistake people will make is read "textual names registry" and then just do that and not notice that "sha1" isn't right, so this lets you read both.

the legends say this is why microsoft had to skip windows 9

But I really don't care either way, I just don't see it causing problems

moparisthebest: ShaOne

Anyways, fixed

LGTM!