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).
lovetoxthis is from 17.3, rule 10.
lovetoxwhat are MUC extensions in that context?
antranigvhas left
antranigvhas joined
MSavoritias (fae,ve)has left
larmahas joined
jubalhhas left
thomaslewishas joined
Ge0rGlovetox: that reads like GC1.0 join, which we luckily killed with fire a few years ago
lovetoxi wanted to know what the words MUC Extensions mean in the context of a presence
lovetoxit MUST include it
lovetoxwhat is a MUC Extension
Ge0rGThe extension is probably the <x xmlns='http://jabber.org/protocol/muc#user'> payload
lovetoxso do i read this correctly, a service MUST add a x element with a MUC related namespace, in EVERY Presence it sends
Ge0rGI think this is only related to the immediate response to a join presence
spiralhas joined
lovetoxok so also in an error presence as a response to a join?
TheRealkaranohas left
TheRealkaranohas joined
antranigvhas left
antranigvhas joined
Ge0rGThe previous wording was:
> A MUC service MUST send extended presence to a client even if the client did not send an empty <x/> ele
Ge0rGChanged in 2011
Ge0rG0045 is not the best worded of XEPs, so maybe it makes sense to remove this point
MSavoritias (fae,ve)has joined
atomicwatchhas left
pasdesushihas left
antranigvhas left
pasdesushihas joined
antranigvhas joined
dezanthas left
FireFlyhas left
FireFlyhas joined
thomaslewishas left
spiralhas left
PapaTutuWawahas left
marc0shas left
marc0shas joined
dezanthas joined
spiralhas joined
marc0shas left
marc0shas joined
lovetoxhow would that help ..
lovetoxim trying to figure out if a MUC service must include <x xmlns='somemucnamespace#> in presences
Ge0rGlovetox: I don't see how it could make any sense, so removing it would make the XEP clearer?
Ge0rGlovetox: in which presences?
lovetoxin all
Ge0rGwell, occupant presences are supposed to have the <x> user element, which other presences are there?
lovetoxerror presence in response to a join, for example, banned, or password needed etc etc
Ge0rGhow would an error presence with that <x> element look?
PapaTutuWawahas joined
Laurahas left
Ge0rGis it legitimate for a <presence> to contain both the <x> and an error? The examples imply such a thing
spiralhas left
kikuchiyohas left
stpeterhas joined
atomicwatchhas joined
lovetoxit is legitimate to send the content of the presence back as error
lovetoxobviously if i join, i send <x> with it
lovetoxbut some impl dont do this
Laurahas joined
lovetoxso the question is, if the xep intends that they should, if not mirror the initial presence, at least include the <x>
spiralhas joined
lovetoxits weird to me from a spec point, that all presences include <x>, but not error presences
Ge0rGlovetox: original 0045 allowed joining a room with a presence that doesn't have <x>
Ge0rGgroupchat 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
thomaslewishas joined
lovetoxfrom 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
thomaslewishas left
stpeterhas left
marc0shas left
marc0shas joined
kikuchiyohas joined
thomaslewishas joined
qyDo you think that could have been avoided with foreknowledge, or is it a direct consequence of flexibility?
spiralhas left
Ge0rGit's a consequence of bad protocol design, and by bad design I mean twenty years of moving forward the state of the art ;)
Ge0rGCarbons and MAM are pretty bad designs that only result from avoiding breaking changes
qySo yeah, could have been avoided with some precognition
qyShame
Ge0rGqy: computers and IM were very different twenty years ago
qyOfc
spiralhas joined
qyIm not lamenting it, i dont mind much, was just wondering why
Laurahas left
Ge0rGXEP-0045 was an attempt to make IRC channels better
lovetoxits just not consitently a first class citizen
atomicwatchhas left
thomaslewishas left
lovetoxthere is type=groupchat, which is good, its clear what we deal with here
lovetoxbut yeah then there are messages which are not type=groupchat, but can still be from a groupchat
Laurahas joined
lovetoxpresences with <x mucnamespace>
lovetoxbut yeah also presences without it
thomaslewishas joined
Ge0rGlovetox: error presence is always a response to a presence you sent
lovetoxif i would design a protocol, single chat and groupchat would be separated pretty hard in ALL aspects
lovetoxGe0rG, 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✎
Marandaor private messages which are of type chat ✏
lovetoxthats for me in practice, it generates much development overhead
lovetoxyeah thats my favorite, private dm type=chat
MarandaIn theory that should be fixed with ... MIX where everything is type "groupchat" ... maybe ... sorta, If I did glance at 0369 correctly.
Marandaat least the message payloads
qyI get the impression MIX is in the realm of vaporware atm
dropshas left
MarandaMore than vaporware, bloatware
Marandait was supposed to simplify stuff but then someone decided it was good to add PubSub to it which extremely complicated stuff instead.
MarandaAs usual in the best of XMPP traditions.
nikhas left
thomaslewishas left
marc0shas left
marc0shas joined
FireFlyhas left
FireFlyhas joined
FireFlyhas left
FireFlyhas joined
debaclehas joined
xnamedhas left
spiralhas left
spiralhas joined
stpeterhas joined
stpeterhas left
nikhas joined
thomaslewishas joined
Dele Olajidehas left
Samhas left
spiralhas left
norayrhas left
norayrhas joined
Samhas joined
rubihas left
rubihas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
thomaslewishas left
adxhas joined
rubihas left
rubihas joined
Menelhas left
spiralhas joined
emusMattJ: can we place the new images in the wiki?
dezanthas left
dezanthas joined
thomaslewishas joined
nikhas left
pasdesushihas left
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.
moparisthebesthas left
ZashSource: I was there, 3000 years ago, when the courage of... I mean when the early design was drawn up at a Summit
moparisthebesthas joined
marc0shas left
marc0shas joined
pasdesushihas joined
thomaslewishas left
marc0shas left
marc0shas joined
thomaslewishas joined
SamWhat 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)
SamSorry, 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?
nikhas joined
SamAnd "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?
thomaslewishas left
Link MauveSam, you take its SHA-1.
thomaslewishas joined
Mx2has left
Mx2has joined
FireFlyhas left
FireFlyhas joined
thomaslewishas left
SamLink Mauve: I don't understand how that relates to the question
SamI'd rephrase, but I can't tell what the ambiguity or confusion is
Dele Olajidehas joined
Link MauveSam, 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.
ZashWe 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 MauveErr, I confused SID and CID, sorry.
ZashProbably consider it a failure
Link MauveWhen 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 MauveFor sending, you should aim at not sending anything invalid ever.
SamLink Mauve: you're saying "only support sha1?"
pasdesushihas left
SamIn that second question my confusion is that I have no good way to decide what hash to use if multiple are supported
Link MauveSam, yes, bob only supports SHA-1 IIRC.
Link MauveIt doesn’t do XEP-0300’s hash agility.
homebeachhas left
Matrix Traveler (bot)has left
homebeachhas joined
Matrix Traveler (bot)has joined
Link MauveSame as avatars, same as 0115.
SamI don't think that's true
SamIt mentions algo+hash, and I don't see anything that says "algo always == sha1"
spiralhas left
Link MauveWanna bet how many clients will support anything but SHA-1, given it’s the only algo used in the examples? ^^'
SamMaybe 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
SamWe 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
pasdesushihas joined
nephelehas left
Link MauveSam, some specs have been updated for that ability, like 0115 → 0390.
Link MauveActually 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.
SamOh 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 MauveIt 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.
spiralhas joined
SamIIRC 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)
Samoh, 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
Zashand like https://xmpp.org/extensions/xep-0300.html it's different from the 'sha1' used in BoB
SamAnyways, without re-inventing the world I'm now even more stumped about how to implement this properly and my original two questions.
SamMaybe 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.
ZashTime to snort up some Second Syndrome and write BoB 2!
SamHonestly, 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
Zashhttps://www.rfc-editor.org/rfc/rfc6920.html mapped to XMPP mayhaps?
Samhuh, TIL they have multiple specs for URLs containing hashes.
ZashJust like us!
debaclehas left
SamThat registry seems more complete at least
ZashA-B all the specs
debaclehas joined
moparisthebestmaybe 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
Samhuh, that's an interesting idea, although I kind of can't imagine it would accomplish anything
antranigvhas left
Dele Olajidehas left
raghavgururajanhas joined
pulkomandyhas joined
spiralhas left
FireFlyhas left
FireFlyhas joined
PapaTutuWawahas left
spiralhas joined
Ingolfhas left
Samoh wait, this named information registry doesn't have sha1 in it… so really both these iana registries are pretty useless.
SamI 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
SamI 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.
Link MauveI’d recommend against adding sha-1 as supported though.
Link MauveCurrent version says sha1, let’s keep it at it and not add newer unsupported names for the same thing.
antranigvhas left
SamThat's for forward compatibility, but yah, I could go either way.
SamNote that it's only supported when reading, not writing so in theory it never gets used.
SamAlso went ahead and submitted a suggestion in response to the form discussion the other day. https://github.com/xsf/xeps/pull/1194\
SamI 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.
antranigvhas joined
Link MauveSam, don’t assume someone won’t mess it up, and then every implementation would be forced to add compatibility just for it.
Link MauveIf it’s downright forbidden, then nothing has to change.
Mx2has left
moparisthebestif algo.toLower().startsWith("sha") && algo.endsWith("1") { SHA1 }
what could possibly go wrong? :P
SamI'm not sure what you mean by that; that's part of the point, if they mess it up we can still read either
SamThe 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.
moparisthebestthe legends say this is why microsoft had to skip windows 9
SamBut I really don't care either way, I just don't see it causing problems