-
lovetox
regarding 0045
-
lovetox
> 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).
-
lovetox
this is from 17.3, rule 10.
-
lovetox
what are MUC extensions in that context?
-
Ge0rG
lovetox: that reads like GC1.0 join, which we luckily killed with fire a few years ago
-
lovetox
i wanted to know what the words MUC Extensions mean in the context of a presence
-
lovetox
it MUST include it
-
lovetox
what is a MUC Extension
-
Ge0rG
The extension is probably the <x xmlns='http://jabber.org/protocol/muc#user'> payload
-
lovetox
so do i read this correctly, a service MUST add a x element with a MUC related namespace, in EVERY Presence it sends
-
Ge0rG
I think this is only related to the immediate response to a join presence
-
lovetox
ok so also in an error presence as a response to a join?
-
Ge0rG
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
-
Ge0rG
Changed in 2011
-
Ge0rG
0045 is not the best worded of XEPs, so maybe it makes sense to remove this point
-
lovetox
how would that help ..
-
lovetox
im trying to figure out if a MUC service must include <x xmlns='somemucnamespace#> in presences
-
Ge0rG
lovetox: I don't see how it could make any sense, so removing it would make the XEP clearer?
-
Ge0rG
lovetox: in which presences?
-
lovetox
in all
-
Ge0rG
well, occupant presences are supposed to have the <x> user element, which other presences are there?
-
lovetox
error presence in response to a join, for example, banned, or password needed etc etc
-
Ge0rG
how would an error presence with that <x> element look?
-
Ge0rG
is it legitimate for a <presence> to contain both the <x> and an error? The examples imply such a thing
-
lovetox
it is legitimate to send the content of the presence back as error
-
lovetox
obviously if i join, i send <x> with it
-
lovetox
but some impl dont do this
-
lovetox
so the question is, if the xep intends that they should, if not mirror the initial presence, at least include the <x>
-
lovetox
its weird to me from a spec point, that all presences include <x>, but not error presences
-
Ge0rG
lovetox: original 0045 allowed joining a room with a presence that doesn't have <x>
-
Ge0rG
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
-
lovetox
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
-
qy
Do you think that could have been avoided with foreknowledge, or is it a direct consequence of flexibility?
-
Ge0rG
it's a consequence of bad protocol design, and by bad design I mean twenty years of moving forward the state of the art ;)
-
Ge0rG
Carbons and MAM are pretty bad designs that only result from avoiding breaking changes
-
qy
So yeah, could have been avoided with some precognition
-
qy
Shame
-
Ge0rG
qy: computers and IM were very different twenty years ago
-
qy
Ofc
-
qy
Im not lamenting it, i dont mind much, was just wondering why
-
Ge0rG
XEP-0045 was an attempt to make IRC channels better
-
lovetox
its just not consitently a first class citizen
-
lovetox
there is type=groupchat, which is good, its clear what we deal with here
-
lovetox
but yeah then there are messages which are not type=groupchat, but can still be from a groupchat
-
lovetox
presences with <x mucnamespace>
-
lovetox
but yeah also presences without it
-
Ge0rG
lovetox: error presence is always a response to a presence you sent
-
lovetox
if i would design a protocol, single chat and groupchat would be separated pretty hard in ALL aspects
-
lovetox
Ge0rG, yes its stuff like this "yeah its a repsonse so the client probably can figure out itself whats this about"
-
Maranda
> <lovetox> presences with <x mucnamespace> or private messages with are of type chat✎ -
Maranda
or private messages which are of type chat ✏
-
lovetox
thats for me in practice, it generates much development overhead
-
lovetox
yeah thats my favorite, private dm type=chat
-
Maranda
In theory that should be fixed with ... MIX where everything is type "groupchat" ... maybe ... sorta, If I did glance at 0369 correctly.
-
Maranda
at least the message payloads
-
qy
I get the impression MIX is in the realm of vaporware atm
-
Maranda
More than vaporware, bloatware
-
Maranda
it was supposed to simplify stuff but then someone decided it was good to add PubSub to it which extremely complicated stuff instead.
-
Maranda
As usual in the best of XMPP traditions.
-
emus
MattJ: can we place the new images in the wiki?
-
Zash
> 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.
-
Zash
Source: I was there, 3000 years ago, when the courage of... I mean when the early design was drawn up at a Summit
-
Sam
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
-
Sam
)
-
Sam
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?
-
Sam
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?
-
Link Mauve
Sam, you take its SHA-1.
-
Sam
Link Mauve: I don't understand how that relates to the question
-
Sam
I'd rephrase, but I can't tell what the ambiguity or confusion is
-
Link Mauve
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.
-
Zash
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?
-
Link Mauve
Err, I confused SID and CID, sorry.
-
Zash
Probably consider it a failure
-
Link Mauve
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.
-
Link Mauve
For sending, you should aim at not sending anything invalid ever.
-
Sam
Link Mauve: you're saying "only support sha1?"
-
Sam
In that second question my confusion is that I have no good way to decide what hash to use if multiple are supported
-
Link Mauve
Sam, yes, bob only supports SHA-1 IIRC.
-
Link Mauve
It doesn’t do XEP-0300’s hash agility.
-
Link Mauve
Same as avatars, same as 0115.
-
Sam
I don't think that's true
-
Sam
It mentions algo+hash, and I don't see anything that says "algo always == sha1"
-
Link Mauve
Wanna bet how many clients will support anything but SHA-1, given it’s the only algo used in the examples? ^^'
-
Sam
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
-
Sam
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
-
Maranda
> <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
-
Link Mauve
Sam, some specs have been updated for that ability, like 0115 → 0390.
-
Link Mauve
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.
-
Sam
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
-
Link Mauve
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.
-
Sam
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)
-
Sam
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
-
Zash
and like https://xmpp.org/extensions/xep-0300.html it's different from the 'sha1' used in BoB
-
Sam
Anyways, without re-inventing the world I'm now even more stumped about how to implement this properly and my original two questions.
-
Sam
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.
-
Zash
Time to snort up some Second Syndrome and write BoB 2!
-
Sam
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
-
Zash
https://www.rfc-editor.org/rfc/rfc6920.html mapped to XMPP mayhaps?
-
Sam
huh, TIL they have multiple specs for URLs containing hashes.
-
Zash
Just like us!
-
Sam
That registry seems more complete at least
-
Zash
A-B all the specs
-
moparisthebest
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
-
Sam
huh, that's an interesting idea, although I kind of can't imagine it would accomplish anything
-
Sam
oh wait, this named information registry doesn't have sha1 in it… so really both these iana registries are pretty useless.
-
Sam
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
-
Sam
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.
-
Zash
That's one approach
-
Sam
Suggested fix: https://github.com/xsf/xeps/pull/1193
-
Link Mauve
I’d recommend against adding sha-1 as supported though.
-
Link Mauve
Current version says sha1, let’s keep it at it and not add newer unsupported names for the same thing.
-
Sam
That's for forward compatibility, but yah, I could go either way.
-
Sam
Note that it's only supported when reading, not writing so in theory it never gets used.
-
Sam
Also went ahead and submitted a suggestion in response to the form discussion the other day. https://github.com/xsf/xeps/pull/1194\
-
Sam
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.
-
Link Mauve
Sam, don’t assume someone won’t mess it up, and then every implementation would be forced to add compatibility just for it.
-
Link Mauve
If it’s downright forbidden, then nothing has to change.
-
moparisthebest
if algo.toLower().startsWith("sha") && algo.endsWith("1") { SHA1 } what could possibly go wrong? :P
-
Sam
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
-
Sam
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.
-
moparisthebest
the legends say this is why microsoft had to skip windows 9
-
Sam
But I really don't care either way, I just don't see it causing problems
-
qy
moparisthebest: ShaOne
-
Sam
Anyways, fixed
-
Link Mauve
LGTM!