moparisthebest, your post with Comcast on the SRV issue was amusingly written, brightened up my day :)✎
jonasw
moparisthebest, 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
Ge0rG
Why 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)?
daniel
Ge0rG: I always use &xep77; on the first time. But I agree it would be better if it only displayed the full name once
daniel
Probably not easy
Ge0rG
daniel: computers were created to automate this sort of thing.
Kev
If you can make the xslt do that, I'm sure people will be grateful.
Ge0rG
I can't. And I'm not sure I want to learn how to.
Ge0rG
If I was immediately able to do it, I'd just implement it straight away and PR.
Kev
Exactly :)
Ge0rG
jonasw: you are our in-house XSLT expert with some free time available, now that your exam is over.
Ge0rGhas left
jonasw
will probably be tricky with XSLT 1.x
Steve Killehas left
Steve Kille
I use `&xep0077;` in MIX
Steve Kille
I tried <cite> once and it was badly broken
Ge0rG
So every XEP reference turns into the full text?
suzyohas joined
Steve Kille
I 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
Ge0rG
It would also be good to be able to link to specific sections of an XEP
ralphmhas left
Ge0rGhas left
Guus
poor 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
marc
Ge0rG, 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
Ge0rG
marc: Yes, this is a valid reading of the RFC.
marc
Ge0rG, Good. Which is why xmpp://xxx?register doesn't make sense
Ge0rG
marc: but what message would xmpp://juliet@example.com/romeo@example.com?register convey?
marc
Well this doesn't make sense IMO because you can not register an account for a given account
@Alacerhas left
@Alacerhas joined
Ge0rG
marc: I would argue that xmpp://juliet@example.com?register would make sense, though, in the sense that you should register the account specified.
Kev
marc: That's not a full JID. That's a bare JID.
marc
Kev, yes, I know :-/
marc
Ge0rG, 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
marc
Ge0rG, 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
Ge0rG
I imagined it would be less text, but somehow it ended up rather complex: https://op-co.de/tmp/user-invite.html
Ge0rGhas left
jonasw
is this ready for protoxep submission?
Ge0rG
jonasw: not yet
jonasw
what’s missing?
Ge0rG
jonasw: there is a dozen of TODOs inside
jonasw
we’ve got accepted XEPs which have that too
Kevhas left
Kevhas left
jonasw
(bind2 I think)
jonasw
(or had)
Kev
TODOs aren't a problem, I think.
Kev
(Sometimes even TODOs that make it unimplementable, depending on the circumstances)
Ge0rG
I don't feel finished yet.
Ge0rG
Besides, we won't get it into today's council anyway, will we?
Kev
Could if it's urgent I suppose, but not otherwise.
Ge0rG
I don't think it is. Adding urgency won't make more people contribute to the public discussion.
Ge0rG
It'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 Cridland
TODOs are a lot less of a problem than unsubmitted XEPs.
ralphmhas left
Ge0rG
Hey 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.
Ge0rG
But I haven't completely understood the flow and conditions, so I might err.
Ge0rG, 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.
Ge0rG
Dave 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 Cridland
Ge0rG, 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
Ge0rG
Dave Cridland: that assumption is technically as valid as "the user can TOTP authenticate every single time"
Dave Cridland
Ge0rG, Right. But if you incrememnt the counter only on success, then it's susceptible to a replay attack, I think.
Ge0rG
Dave 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.
Ge0rG
Dave Cridland: a replay of what exactly?
vanitasvitaehas joined
Ge0rGhas left
Dave Cridland
Ge0rG, The client-initial-response, specifically.
Dave Cridland
Ge0rG, 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.
Ge0rG
Dave 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
jonasw
Dave Cridland, found a typo in the rfc draft (section 6.2):
multiple values for Counter, increasingly the likelyhood of
discovering a match.
jonasw
*increasingly*
jonasw
Dave Cridland, ha, I was about to say that with the Two Generals :)
Link Mauvehas joined
Dave Cridland
jonasw, Ah, yes. Should be "increasingly the likelyhoodly of discoveringly a match" of course.
jonasw
Dave 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?
jonasw
specifically, is the counter only used to prevent replays without knowledge of the secrets involved?
Dave Cridland
jonasw, 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.
jonasw
do we really need that, or can’t we say that 128bit of random nonce shall be enough for everyone?
Dave Cridland
jonasw, Ah, so no. A counter is used because it's predictably changing state.
jonasw
I don’t see the purpose of the counter quite yet
Dave Cridland
jonasw, We could also use NotACounter = H(NotACounter) each time.
jonasw
sure
jonasw
in SCRAM, the nonce is composed of two parts (one from the server and one from the client), wouldn’t that work?
Dave Cridland
jonasw, 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.
jonasw
marc, please see https://github.com/xsf/xeps/pull/568#issuecomment-356583982
Dave Cridland
jonasw, 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.
jonasw
mh
marc
jonasw, is there a way to sign it without registering on GitHub?
jonasw
marc, I was expecting that. Kev ^?
marc
jonasw, I can send you a handwritten letter for example
Kev
No clue, I wasn't involved in setting up the CLA stuff.
jonasw
marc, I think we handled that via email before the CLAbot thing was invented.
jonasw
I have no idea where the email went normally though, I need to figure that out.
jonasw
I’ll just do what SamWhited did to me back then.
Ge0rGhas left
Kev
Getting someone to email in the agreement seems sufficient to me.
jonasw
marc, I sent you an email, please reply keeping the CC intact.
marc
jonasw, just replying a "+1"? :)
jonasw
if you want to be super safe, copy the IPR policy into your reply; but +1 is essentially what I did.
marc
jonasw, okay, thanks for the mail. I'll read the policy and reply then
Dave Cridlandhas left
Dave Cridlandhas left
zinid
moparisthebest, you said you don't know clueless admins, here is one: https://github.com/processone/ejabberd/issues/2214
tux
I 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/
just found that https://github.com/mgp25/Chat-API/wiki/FunXMPP-Protocol
edhelas
is 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
marc
jonasw, Done
danielhas left
danielhas joined
Zash
edhelas: 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.
edhelas
but is it nocieably better than ZLIB ?
edhelas
I 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
intosi
I 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.
How 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
Ge0rG
I think identity management is the weakest link in OMEMO.
Steve Killehas left
moparisthebest
Ge0rG, iirc everyone has to be on everyone's contact list
Ge0rG
moparisthebest: that's a prerequisite to knowing their keys, except with omemo_for_all
Zash
or the omemo key nodes need to be public
Ge0rG
moparisthebest: it's not a security guarantee of any kind, especially if you consider that the roster is owned by the server.
zinid
moparisthebest: so I should tell him "choose another career"?
ralphmhas joined
moparisthebest
Ge0rG, I *thought* the key had to be trusted too, but maybe not with BTBV not sure
moparisthebest
zinid, yes 🙂
Ge0rG
moparisthebest: so only friends can snoop on friends?
Ge0rGhas left
zinid
moparisthebest: 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
Anu
Hi all. I'll be lurking here for a bit.
Ge0rG
Hi Anu!
intosi
Hello, Anu!
Anu
Hi
jonasw
welcome, Anu
Guus
if you lurk long enough, we'll ask you to do the dishes though.
Anu
hahah
Anu
Sorry, old irc habit. join a channel and watch a little before jumping in.
daniel
Anu, 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)
Guus
I was going to say that IRC is so 1999 - but that's probably not old enough :)
Kev
I still actively use IRC now :p
jonasw
Anu, in general, a good habit I think :)
Holger
XMPP is 1999 ...
Zash
80's something?
Anu
I was talking on IRC during the gulf war..
Zash
Oh but apparently with IRCv3 they've got JSON and all the features
moparisthebest
yea but it's like MIX
daniel
which one?
moparisthebest
all spec'd out and no one in sight wants to implement it
Anu
I should properly introduce myself. I am Anu Pokharel, I develop Monal for iOS and OSX
Ge0rGhas left
Anu
1990 gulf war
Guus
good to have you hear, Anu (we'll still ask you to do the dishes, eventually)
Ge0rG
Anu: actually it's awesome to have you here. Now we can complain even more about Monal ;-)
MattJ
After the Board decides which dishes to wash first
Anu
complaints mean people use it i guess. :)
Dave Cridlandhas left
Ge0rG
Anu: actually I have a hobby of installing XMPP software and flooding the developers with issue reports.
MattJ
:'(
intosi
Anu: Ge0rG isn't joking.
Anu
Oh i know, Ive seen the bugs that hes sent me
intosi
;)
moparisthebest
if it wasn't for Ge0rG and Link Mauve no XMPP software would have any issues
moparisthebest
at least, reported issues
Anu
It's great. I've come to really appreciate people who test code for me.
Ge0rG
https://github.com/anurodhp/Monal/issues?utf8=%E2%9C%93&q=is%3Aissue+author%3Age0rg - way too few, if compared with prosody or poezio.
Ge0rG
But on the other hand, I'm not actively using the iPhone, it's just a dev device.
ralphmhas joined
mathieuii
at least Anu is safe, Link Mauve has no apple device
Steve Killehas joined
Anu
I'm halfway through porting all the iOS code to a mac UI.
Anu
I hope to get more bugs then
marc
Anu, screenshots of your App would be nice
danielhas left
Ge0rG
Anu: in Monal/iOS I see many of my offline contacts listed multiple times. Restarting the app fixes it though.
Ge0rG
Anu: 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
Anu
Also, 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 :)
marc
pep., you forgot to mention Ge0rG :)
jonasw
I just hit the "merge" and "send" buttons
jonasw
(and even screwed up the merge)
pep.
Ge0rG, ^
Anuhas left
Ge0rG
jonasw: squash & merge?
jonasw
Ge0rG, nah, more like "first ask for IPR signature, then merge" :)
Dave Cridlandhas left
Dave Cridlandhas left
marc
jonasw, actually I don't understand why you merged it into master right now
jonasw
marc, why not?
marc
jonasw, I try to keep my master branches clean
Kev
But it's in the inbox, no?
Kev
So this *is* clean.
Kev
The inbox holds protoXEPs submitted for approval, but not yet Experimental.
marc
I'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
marc
pep., my is :D
pep.
How many rebase and push force does that take you
Kev
I think I don't understand the question. There was a PR requesting this be merged to master, so Jonas did. Isn't that right?
jonasw
marc, the only way to make the website update is to push to master
jonasw
that might be the bit of info you’re lacking
marc
jonasw, ah okay
pep.
plus yeah it doesn't apply here
marc
Didn'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
Guus
I feel neglected.
Guus
(as I'm pretty sure mine has most bugs of all :P )
Anu
Guus, do you have an iOS device, want to test monal ?
Guus
Anu: sorry, android
Guus
(although I was referring to the lack of issue flood from Ge0rG)
Ge0rG
Guus: sorry, my time is limited.
Guus
(test)
danielhas left
zinidhas left
Ge0rGhas left
zinidhas left
Ge0rG
Damn, my iPhone won't get detected by my VirtualBox.
Ge0rGhas left
moparisthebest
probably have to do USB passthrough or something?
suzyohas joined
Ge0rG
Yes. 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/>?
jonasw
pep., ad-hoc allows use from clients which don’t support the protocol yet
pep.
Does many client support ad-hoc already?
jonasw
sure
jonasw
even pidgin(!) does
pep.
Do
jonasw
gajim does, poezio does
pep.
Conversations? Dino
jonasw
dunno about those
pep.
yaxim
jonasw
but you can always implement a specific ad-hoc flow without implementing all of ad-hoc or a generic ad-hoc UI
jonasw
so 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
moparisthebest
conversations definitly no, dino I think not
Ge0rG
pep.: 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
jonasw
pep., 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
jonasw
pep., 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
jonasw
no
Ge0rG
pep.: your clients are bad then :P
pep.
If they want to use this
jonasw
no
pep.
no?
jonasw
they 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?
jonasw
exatcly
Ge0rG
pep.: yes, except that now there are already clients that support this
Ge0rG
so for a client not yet supporting ad-hoc, it doesn't matter. And for clients supporting ad-hoc, they get it for free
jonasw
yupp
jonasw
and 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
jonasw
no
jonasw
not everything makes sense as an ad-hoc command
jonasw
MAM 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)
jonasw
roster wouldn’t make any sense either, a client needs proper support for a roster for it to be useful.
Ge0rGhas left
pep.
hmm
mathieuii
jonasw, there are the server admin commands XEP which can be singled out by the client
jonasw
mathieuii, sure
jonasw
a client can always additionally implement fancy additional support for a given Ad-Hoc Command
jonasw
but the command has to work well even without specific support
mathieuii
yeah, 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
jonasw
pep., there are specific rules how unknown fields are treated in forms
pep.
And lost all the interest of using ad-hoc
jonasw
if 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
jonasw
sure
jonasw
things are worse with IQs though
jonasw
if 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
Ge0rG
pep.: XMPP is full of defined-but-if-if-if
pep.
yeah :/
jonasw
pep., it’s fully defined
jonasw
but 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
jonasw
no, 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
Ge0rG
jonasw: 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
Ge0rG
pep.: you can always introduce a different command name.
Ge0rG
pep.: which is exactly like a namespace bump
pep.
invite2
jonasw
Ge0rG, 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
Ge0rG
pep.: 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
Ge0rG
marc: 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
moparisthebest
ew
moparisthebest
why not T and F and Y and N also
moparisthebest
I mean if you are going down that rabbit hole, might as well see how deep
suzyohas joined
Ge0rG
moparisthebest: it's merely about whether ibr= should be `true`, `1` or `y`
Ge0rG
I'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
Ge0rG
So, 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?
MattJ
To the user bare JID, intercepted by the MUC
Ge0rG
MattJ: forwarded to the bare JID?
MattJ
Yes
MattJ
MUC service handles everything addressed to participant JIDs
Ge0rG
Because sending the IQ get to the MUC bare JID won't work out very well
MattJ
What "handling" means isn't greatly defined, but a sensible MUC service will handle vcard requests by proxying to the user's bare JID
Ge0rG
is there a XEP for that?
MattJ
nafaik
MattJ
It's just an implementation thing
Ge0rG
Isn't that what XEPs are made for?
Ge0rGhas left
MattJ
The MUC service could return a service-specific vcard (e.g. you have a muc.xmpp.org profile)
MattJ
and still be compliant
MattJ
unless someone can prove me wrong :)
Anuhas left
Ge0rG
MattJ: 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
Ge0rG
Dave 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
marc
Ge0rG, 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?