jonaswmoparisthebest, your post with Comcast on the SRV issue was amusingly written, brightened up my day :)
jonaswmoparisthebest, your post with Comcast on the SRV issue was written amusingly, brightened up my day :)
danielhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
danielhas left
danielhas joined
Ge0rGhas left
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
ralphmhas joined
Ge0rGhas left
suzyohas joined
Dave Cridlandhas left
Dave Cridlandhas joined
danielhas left
danielhas joined
Ge0rGhas left
danielhas left
zinidhas left
danielhas left
Dave Cridlandhas left
Dave Cridlandhas joined
danielhas left
danielhas joined
Steve Killehas left
Dave Cridlandhas left
Dave Cridlandhas joined
Ge0rGhas left
Steve Killehas joined
Dave Cridlandhas left
Dave Cridlandhas joined
suzyohas joined
tuxhas joined
tuxhas joined
Ge0rGWhy do we have `&xep0077;` and `<cite>XEP-0077</cite>` na neitiher works as expected (show the full name on first occurence and just a hyperlink on any later one)?
danielGe0rG: I always use &xep77; on the first time. But I agree it would be better if it only displayed the full name once
danielProbably not easy
Ge0rGdaniel: computers were created to automate this sort of thing.
KevIf you can make the xslt do that, I'm sure people will be grateful.
Ge0rGI can't. And I'm not sure I want to learn how to.
Ge0rGIf I was immediately able to do it, I'd just implement it straight away and PR.
KevExactly :)
Ge0rGjonasw: you are our in-house XSLT expert with some free time available, now that your exam is over.
Ge0rGhas left
jonaswwill probably be tricky with XSLT 1.x
Steve Killehas left
Steve KilleI use `&xep0077;` in MIX
Steve KilleI tried <cite> once and it was badly broken
Ge0rGSo every XEP reference turns into the full text?
suzyohas joined
Steve KilleI don't think this is so bad. Someone fixed up the much more problematic issue of duplicates in the reference list, which was a big win (thanks to whoever sorted it)
lskdjfhas joined
Ge0rGIt would also be good to be able to link to specific sections of an XEP
ralphmhas left
Ge0rGhas left
Guuspoor Jonas :)
Alexhas joined
Zashhas left
Ge0rGhas left
danielhas left
moparisthebesthas left
danielhas joined
lskdjfhas joined
moparisthebesthas joined
Ge0rGhas left
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
ralphmhas joined
Ge0rGhas left
Ge0rGhas left
suzyohas joined
blablahas left
danielhas left
blablahas joined
marchas joined
Dave Cridlandhas left
Dave Cridlandhas joined
tuxhas joined
ralphmhas left
blablahas joined
blablahas joined
Ge0rGhas left
danielhas joined
Guushas left
Ge0rGhas left
la|r|mahas joined
Dave Cridlandhas left
Dave Cridlandhas joined
lskdjfhas joined
marcGe0rG, If I understand the RFC correctly, the authority component is used to "select" an account. So xmpp://foo@bar.com/juliet@example.com?roster would mean "add juliet@example.com to my roster of account foo@bar.com". Which is why the authority component needs to be a full JID
Ge0rGmarc: Yes, this is a valid reading of the RFC.
marcGe0rG, Good. Which is why xmpp://xxx?register doesn't make sense
Ge0rGmarc: but what message would xmpp://juliet@example.com/romeo@example.com?register convey?
marcWell this doesn't make sense IMO because you can not register an account for a given account
@Alacerhas left
@Alacerhas joined
Ge0rGmarc: I would argue that xmpp://juliet@example.com?register would make sense, though, in the sense that you should register the account specified.
Kevmarc: That's not a full JID. That's a bare JID.
marcKev, yes, I know :-/
marcGe0rG, Yes, but look at the "?register" definition. I think they used xmpp:foo@bar?register on purpose and not xmpp://foo@bar?register
Guushas left
marcGe0rG, However, we agreed that we don't need the inviter JID because it can be faked
Dave Cridlandhas left
Dave Cridlandhas joined
jerehas joined
jerehas joined
Ge0rGhas left
Flowhas joined
Zashhas left
Ge0rGhas left
Dave Cridlandhas left
Dave Cridlandhas left
Ge0rGI imagined it would be less text, but somehow it ended up rather complex: https://op-co.de/tmp/user-invite.html
Ge0rGhas left
jonaswis this ready for protoxep submission?
Ge0rGjonasw: not yet
jonaswwhat’s missing?
Ge0rGjonasw: there is a dozen of TODOs inside
jonaswwe’ve got accepted XEPs which have that too
Kevhas left
Kevhas left
jonasw(bind2 I think)
jonasw(or had)
KevTODOs aren't a problem, I think.
Kev(Sometimes even TODOs that make it unimplementable, depending on the circumstances)
Ge0rGI don't feel finished yet.
Ge0rGBesides, we won't get it into today's council anyway, will we?
KevCould if it's urgent I suppose, but not otherwise.
Ge0rGI don't think it is. Adding urgency won't make more people contribute to the public discussion.
Ge0rGIt's also still self-contradicting in some places.
Alexhas left
Alexhas joined
danielhas left
danielhas joined
Ge0rGhas left
moparisthebesthas joined
Dave Cridlandhas left
lumihas joined
blablahas left
moparisthebesthas joined
Dave CridlandTODOs are a lot less of a problem than unsubmitted XEPs.
ralphmhas left
Ge0rGHey Dave! I've been reading your proto-XEPs, and I have a feeling that CLIENT-KEY counters will get desynced and invalidated if a network outage happens during the handshake.
Ge0rGBut I haven't completely understood the flow and conditions, so I might err.
Dave CridlandGe0rG, You're right. Various things in when, exactly, the counter is incremented could be improved. There are security issues tied in with all of them, though, I think.
Ge0rGDave Cridland: yeah. My question is, how much thought you have put into the exact order of increments, and what the rationale is beyond what's written down.
Dave CridlandGe0rG, But we do assume that if the counter is desynchronized, the legitimate user can always use a password (and TOTP device) anyway.
Link Mauvehas left
Ge0rGDave Cridland: that assumption is technically as valid as "the user can TOTP authenticate every single time"
Dave CridlandGe0rG, Right. But if you incrememnt the counter only on success, then it's susceptible to a replay attack, I think.
Ge0rGDave Cridland: I've experienced many situations where my mobile connection changed multiple times in a row, providing just enough time to the client to begin authentication.
Ge0rGDave Cridland: a replay of what exactly?
vanitasvitaehas joined
Ge0rGhas left
Dave CridlandGe0rG, The client-initial-response, specifically.
Dave CridlandGe0rG, Also, the counter has to be incremented at the same time at both ends. I think we run into a Two Generals problem if we try and make that perfect.
Ge0rGDave Cridland: maybe all we need is some kind of transactional consistency? I'm not sure, I'd just like to rule out that the whole effect is ruined every other day
jonaswDave Cridland, found a typo in the rfc draft (section 6.2):
multiple values for Counter, increasingly the likelyhood of
discovering a match.
jonasw*increasingly*
jonaswDave Cridland, ha, I was about to say that with the Two Generals :)
Link Mauvehas joined
Dave Cridlandjonasw, Ah, yes. Should be "increasingly the likelyhoodly of discoveringly a match" of course.
jonaswDave Cridland, can’t you solve the replay issue (I haven’t dug deep into the draft yet) the same way SCRAM does, with a nonce?
jonaswspecifically, is the counter only used to prevent replays without knowledge of the secrets involved?
Dave Cridlandjonasw, Well, sort of. So yes, but then you'd have to have the server store previous nonces, and ensure they weren't reused. Which feels, well, rubbish.
jonaswdo we really need that, or can’t we say that 128bit of random nonce shall be enough for everyone?
Dave Cridlandjonasw, Ah, so no. A counter is used because it's predictably changing state.
jonaswI don’t see the purpose of the counter quite yet
Dave Cridlandjonasw, We could also use NotACounter = H(NotACounter) each time.
jonaswsure
jonaswin SCRAM, the nonce is composed of two parts (one from the server and one from the client), wouldn’t that work?
Dave Cridlandjonasw, But the idea is that where we see a correct ValidatorKey but an invalid resultant HMAC, we can make a reasonable assumption that the key has been compromised. THough as Ge0rG points out, this also occurs in some network failures.
jonaswmarc, please see https://github.com/xsf/xeps/pull/568#issuecomment-356583982
Dave Cridlandjonasw, Yes, but it would introduce an additional RTT. The right channel binding data would solve this (and we do use this as well), but too many operating systems don't allow clients to get at that.
jonaswmh
marcjonasw, is there a way to sign it without registering on GitHub?
jonaswmarc, I was expecting that. Kev ^?
marcjonasw, I can send you a handwritten letter for example
KevNo clue, I wasn't involved in setting up the CLA stuff.
jonaswmarc, I think we handled that via email before the CLAbot thing was invented.
jonaswI have no idea where the email went normally though, I need to figure that out.
jonaswI’ll just do what SamWhited did to me back then.
Ge0rGhas left
KevGetting someone to email in the agreement seems sufficient to me.
jonaswmarc, I sent you an email, please reply keeping the CC intact.
marcjonasw, just replying a "+1"? :)
jonaswif you want to be super safe, copy the IPR policy into your reply; but +1 is essentially what I did.
marcjonasw, okay, thanks for the mail. I'll read the policy and reply then
Dave Cridlandhas left
Dave Cridlandhas left
zinidmoparisthebest, you said you don't know clueless admins, here is one: https://github.com/processone/ejabberd/issues/2214
tuxI just read that Kontron [1] is implementing MQTT into its communication gateways (LoRa based). Do we have good showcases for using XMPP in a mobile IoT context?
There's a lot of movement currently towareds standardized communication in public transport, but – if at all – I only see MQTT (or SOAP …)
[1] https://www.kontron.de/
edhelasjust found that https://github.com/mgp25/Chat-API/wiki/FunXMPP-Protocol
edhelasis it just a dump version of https://xmpp.org/extensions/xep-0138.html ?
Dave Cridlandhas left
danielhas left
danielhas joined
la|r|mahas left
lumihas left
moparisthebesthas joined
Ge0rGhas left
ralphmhas left
suzyohas joined
moparisthebesthas joined
danielhas left
danielhas joined
Ge0rGhas left
danielhas left
danielhas joined
marcjonasw, Done
danielhas left
danielhas joined
Zashedhelas: yes, a custom compression scheme. they also had their own custom RC4 based encryption scheme and some custom authentication that was not very good. hopefully those are fixed by now.
edhelasbut is it nocieably better than ZLIB ?
edhelasI mean this is just dictionnary compression, can work pretty well on XML
Dave Cridlandhas left
Holgerhas left
ralphmhas joined
Holgerhas joined
Ge0rGhas left
ralphmhas left
ralphmhas joined
intosiI wouldn't expect this to be better in terms of compression on longer sessions, as it doesn't even try to compress jids or body texts.
ZashHe who controls the server controls the universe!
edhelasthat's why they added e2ee… wait
Ge0rGHow is group membership enforced in OMEMO? Is the admin signing the participant key list? Oh, wait. Not defined at all.
edhelas:D
Steve Killehas left
Ge0rGI think identity management is the weakest link in OMEMO.
Steve Killehas left
moparisthebestGe0rG, iirc everyone has to be on everyone's contact list
Ge0rGmoparisthebest: that's a prerequisite to knowing their keys, except with omemo_for_all
Zashor the omemo key nodes need to be public
Ge0rGmoparisthebest: it's not a security guarantee of any kind, especially if you consider that the roster is owned by the server.
zinidmoparisthebest: so I should tell him "choose another career"?
ralphmhas joined
moparisthebestGe0rG, I *thought* the key had to be trusted too, but maybe not with BTBV not sure
moparisthebestzinid, yes 🙂
Ge0rGmoparisthebest: so only friends can snoop on friends?
Ge0rGhas left
zinidmoparisthebest: very clever
Holgerhas joined
jjrhhas left
blablahas left
Ge0rGhas left
Dave Cridlandhas left
Dave Cridlandhas left
Anuhas joined
danielhas left
jjrhhas left
jjrhhas left
ralphmhas joined
Ge0rGhas left
AnuHi all. I'll be lurking here for a bit.
Ge0rGHi Anu!
intosiHello, Anu!
AnuHi
jonaswwelcome, Anu
Guusif you lurk long enough, we'll ask you to do the dishes though.
Anuhahah
AnuSorry, old irc habit. join a channel and watch a little before jumping in.
danielAnu, probably introduce yourself very quickly. i'm not sure everyone recognizes you by name. (I only figured that out myself because you contact me 1:1)
GuusI was going to say that IRC is so 1999 - but that's probably not old enough :)
KevI still actively use IRC now :p
jonaswAnu, in general, a good habit I think :)
HolgerXMPP is 1999 ...
Zash80's something?
AnuI was talking on IRC during the gulf war..
ZashOh but apparently with IRCv3 they've got JSON and all the features
moparisthebestyea but it's like MIX
danielwhich one?
moparisthebestall spec'd out and no one in sight wants to implement it
AnuI should properly introduce myself. I am Anu Pokharel, I develop Monal for iOS and OSX
Ge0rGhas left
Anu1990 gulf war
Guusgood to have you hear, Anu (we'll still ask you to do the dishes, eventually)
Ge0rGAnu: actually it's awesome to have you here. Now we can complain even more about Monal ;-)
MattJAfter the Board decides which dishes to wash first
Anucomplaints mean people use it i guess. :)
Dave Cridlandhas left
Ge0rGAnu: actually I have a hobby of installing XMPP software and flooding the developers with issue reports.
MattJ:'(
intosiAnu: Ge0rG isn't joking.
AnuOh i know, Ive seen the bugs that hes sent me
intosi;)
moparisthebestif it wasn't for Ge0rG and Link Mauve no XMPP software would have any issues
moparisthebestat least, reported issues
AnuIt's great. I've come to really appreciate people who test code for me.
Ge0rGhttps://github.com/anurodhp/Monal/issues?utf8=%E2%9C%93&q=is%3Aissue+author%3Age0rg - way too few, if compared with prosody or poezio.
Ge0rGBut on the other hand, I'm not actively using the iPhone, it's just a dev device.
ralphmhas joined
mathieuiiat least Anu is safe, Link Mauve has no apple device
Steve Killehas joined
AnuI'm halfway through porting all the iOS code to a mac UI.
AnuI hope to get more bugs then
marcAnu, screenshots of your App would be nice
danielhas left
Ge0rGAnu: in Monal/iOS I see many of my offline contacts listed multiple times. Restarting the app fixes it though.
Ge0rGAnu: also, do you have a beta channel / testflight?
Anu Ge0rG, yeah its a bug in one my sql queries. Yes, I do send me your apple id. I need more people testing the next update prior to release
AnuAlso, please file a bug for that if there isnt already one so i can make sure its fixed
Ge0rGhas left
danielhas left
pep.marc, jonasw, good to see the XEP up :)
marcpep., you forgot to mention Ge0rG :)
jonaswI just hit the "merge" and "send" buttons
jonasw(and even screwed up the merge)
pep.Ge0rG, ^
Anuhas left
Ge0rGjonasw: squash & merge?
jonaswGe0rG, nah, more like "first ask for IPR signature, then merge" :)
Dave Cridlandhas left
Dave Cridlandhas left
marcjonasw, actually I don't understand why you merged it into master right now
jonaswmarc, why not?
marcjonasw, I try to keep my master branches clean
KevBut it's in the inbox, no?
KevSo this *is* clean.
KevThe inbox holds protoXEPs submitted for approval, but not yet Experimental.
marcI'm talking about Git commit history
pep.marc, I don't think there's any issue with pushing early to master, you commit history is never clean anyway
marcpep., my is :D
pep.How many rebase and push force does that take you
KevI think I don't understand the question. There was a PR requesting this be merged to master, so Jonas did. Isn't that right?
jonaswmarc, the only way to make the website update is to push to master
jonaswthat might be the bit of info you’re lacking
marcjonasw, ah okay
pep.plus yeah it doesn't apply here
marcDidn't think about the website
Ge0rGhas left
Anuhas joined
Dave Cridlandhas left
suzyohas joined
Guus> Ge0rG: Anu: actually I have a hobby of installing XMPP software and flooding the developers with issue
GuusI feel neglected.
Guus(as I'm pretty sure mine has most bugs of all :P )
AnuGuus, do you have an iOS device, want to test monal ?
GuusAnu: sorry, android
Guus(although I was referring to the lack of issue flood from Ge0rG)
Ge0rGGuus: sorry, my time is limited.
Guus(test)
danielhas left
zinidhas left
Ge0rGhas left
zinidhas left
Ge0rGDamn, my iPhone won't get detected by my VirtualBox.
Ge0rGhas left
moparisthebestprobably have to do USB passthrough or something?
suzyohas joined
Ge0rGYes. But it doesn't work.
zinidhas joined
suzyohas joined
efrithas joined
ralphmhas joined
lumihas joined
pep.marc, Ge0rG, any reason why ad-hoc and not say <iq/>?
jonaswpep., ad-hoc allows use from clients which don’t support the protocol yet
pep.Does many client support ad-hoc already?
jonaswsure
jonasweven pidgin(!) does
pep.Do
jonaswgajim does, poezio does
pep.Conversations? Dino
jonaswdunno about those
pep.yaxim
jonaswbut you can always implement a specific ad-hoc flow without implementing all of ad-hoc or a generic ad-hoc UI
jonaswso if there’s interest in this thing, I guess that wouldn’t be a blocker
Dave Cridlandhas left
la|r|mahas joined
Dave Cridlandhas left
moparisthebestconversations definitly no, dino I think not
Ge0rGpep.: yaxim doesn't. But I'd for sure add support for the user-invite command
pep.jonasw, I'm not sure I get your point about clients not supporting the protocol yet
danielhas left
jonaswpep., if you invent a protocol based on non ad-hoc <iq/>s, *all* clients have to be updated to be able to use it.
Guushas left
Dave Cridlandhas left
jonaswpep., if you use ad-hoc, clients which already have ad-hoc support can use the protocol right away.
marchas left
pep.Well here all clients have to implement ad-hoc
pep.first
jonaswno
Ge0rGpep.: your clients are bad then :P
pep.If they want to use this
jonaswno
pep.no?
jonaswthey could always just implement handling for that specific command, without running a full-blown ad-hoc implementation
jonasw(which is simpler)
pep.Which would be the same as handling this specific command via iqs?
jonaswexatcly
Ge0rGpep.: yes, except that now there are already clients that support this
Ge0rGso for a client not yet supporting ad-hoc, it doesn't matter. And for clients supporting ad-hoc, they get it for free
jonaswyupp
jonaswand that’s the beauty of it
pep.Ok, I'm just trying to understand here. So we should start implementing everything via ad-hoc commands right
jonaswno
jonaswnot everything makes sense as an ad-hoc command
jonaswMAM for example; the result wouldn’t be very useful for a user
jonasw(ad-hoc commands are only useful if the result doesn’t need to be interpreted by the client in any way, but only by the user)
jonaswroster wouldn’t make any sense either, a client needs proper support for a roster for it to be useful.
Ge0rGhas left
pep.hmm
mathieuiijonasw, there are the server admin commands XEP which can be singled out by the client
jonaswmathieuii, sure
jonaswa client can always additionally implement fancy additional support for a given Ad-Hoc Command
jonaswbut the command has to work well even without specific support
mathieuiiyeah, sure
pep.Will the ad-hoc command be versioned or something?
pep.If now a client want to special-case it and the XEP gets updated, you now broke everything
jonaswpep., there are specific rules how unknown fields are treated in forms
pep.And lost all the interest of using ad-hoc
jonaswif the XEP updates adhere to that, there should be no issues
pep.k
jonasw(and a client could fallback to the default ad-hoc handling (if it has some))
pep.that's a lot of ifs
jonaswsure
jonaswthings are worse with IQs though
jonaswif you make an update to a raw IQ protocol, this is (usually) a namespace bump, breaking the flow for everyone
jonasw(until the next update)
pep.yeah, but you don't end-up with UB
pep.Or defined-but-if-if-if
Ge0rGpep.: XMPP is full of defined-but-if-if-if
pep.yeah :/
jonaswpep., it’s fully defined
jonaswbut in addition to the defined behaviour, you can also play safe and fall back to generic ad-hoc handling.
pep.But it depends if X has support for Y and Z and
pep.But gotcha
jonaswno, if you supported an earlier version (okay, here’s one "if": and *if* the people updating the XEP didn’t do something stupid), that’ll continue to work
Ge0rGjonasw: the Council should prevent them from doing stupid things
pep.Yeah I think I would prefer to have it versioned and break cleanly with a major update if needed, instead of wanting to stay backward-compatible until the end of times
pep.At costs
Ge0rGpep.: you can always introduce a different command name.
Ge0rGpep.: which is exactly like a namespace bump
pep.invite2
jonaswGe0rG, heh, yes, but that doesn’t always happen :)
ralphmhas joined
Ge0rGhas left
pep.small remark, there doesn't seem to be in 0050 anything that restrict command name usage. Server could be using a conflicting command name, knowing that ad-hoc commands are often used in non-specified environments as I understand it
pep.Though it's the same remark for server admin commands
Ge0rGpep.: yes. namespacing commands is a thin
Ge0rG+g
Dave Cridlandhas left
Dave Cridlandhas left
winfriedhas joined
winfriedhas joined
Anuhas joined
Dave Cridlandhas left
Ge0rGhas left
danielhas left
SamWhitedhas left
danielhas left
Ge0rGhas left
jerehas joined
ralphmhas joined
Dave Cridlandhas left
Ge0rGhas left
Ge0rGmarc: just stumbled upon https://xmpp.org/extensions/xep-0186.html#nt-idm138620103579920
> In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes, the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept 'false' and the strings "1" and "true" for the concept 'true'; implementations MUST support both styles of lexical representation.
winfriedhas joined
winfriedhas joined
moparisthebestew
moparisthebestwhy not T and F and Y and N also
moparisthebestI mean if you are going down that rabbit hole, might as well see how deep
suzyohas joined
Ge0rGmoparisthebest: it's merely about whether ibr= should be `true`, `1` or `y`
Ge0rGI'm not keen on inventing new protocol, just making the xmpp: URI as short as possible
suzyohas joined
Guushas left
danielhas left
Ge0rGhas left
Tobiashas joined
Tobiashas joined
Dave Cridlandhas left
Guushas left
Ge0rGSo, how does XEP-0153 work in a MUC? You send the vcard get IQ to the participant full JID, and it gets forwarded to the user full JID? Intercepted by the user's account?
MattJTo the user bare JID, intercepted by the MUC
Ge0rGMattJ: forwarded to the bare JID?
MattJYes
MattJMUC service handles everything addressed to participant JIDs
Ge0rGBecause sending the IQ get to the MUC bare JID won't work out very well
MattJWhat "handling" means isn't greatly defined, but a sensible MUC service will handle vcard requests by proxying to the user's bare JID
Ge0rGis there a XEP for that?
MattJnafaik
MattJIt's just an implementation thing
Ge0rGIsn't that what XEPs are made for?
Ge0rGhas left
MattJThe MUC service could return a service-specific vcard (e.g. you have a muc.xmpp.org profile)
MattJand still be compliant
MattJunless someone can prove me wrong :)
Anuhas left
Ge0rGMattJ: thanks very much. That helped me better understand the problem space. I hope I was able to make a useful suggestion for pep-vcard-conversion now
Dave Cridlandhas left
Dave Cridlandhas left
ralphmhas joined
Ge0rGhas left
winfriedhas left
winfriedhas joined
Ge0rGDave Cridland: is the issuer name "XMPP" in totp-2fa an example or a normative constant?
Kevhas left
Ge0rGhas left
Dave Cridlandhas left
Dave Cridlandhas left
Zashhas left
la|r|mahas left
la|r|mahas joined
Ge0rGhas left
Dave Cridlandhas left
Dave Cridlandhas left
ralphmhas joined
Ge0rGhas left
Dave Cridlandhas left
Dave Cridlandhas left
ralphmhas left
Ge0rGhas left
ralphmhas joined
lumihas left
lumihas joined
Ge0rGhas left
ralphmhas left
Syndacehas joined
Syndacehas joined
Dave Cridlandhas left
ralphmhas joined
Ge0rGhas left
ralphmhas joined
hanneshas joined
Ge0rGhas left
danielhas left
danielhas joined
waqashas joined
SamWhitedhas joined
Zashhas left
efrithas left
Ge0rGhas left
ralphmhas joined
Dave Cridlandhas left
Dave Cridlandhas left
marcGe0rG, what's the "problem" or why do you mention this?
Zashhas joined
daniel> Because sending the IQ get to the MUC bare JID won't work out very well
Why not? Isn't that where you disco#info to as well?