Is there a simple C++ XMPP library that lets me interact with raw XML?
larmahas left
andyhas joined
larmahas joined
Dele (Mobile)has joined
COM8
I wan't to creat an application that runs on a microcontroller with only 500kByte of ROM
jonas’
COM8, I used libstrophe or libcouplet in the past
jonas’
(both are C)
jonas’
(but should be perfectly usable with C++)
jonas’
example usage in my project: https://github.com/horazont/hint/blob/devel/host/src/xmppintf.c
COM8has left
COM8has joined
COM8
Thanks. will have a look at it
Holger
COM8: http://deusexmachinae.se/dxmpp/ was written with IoT stuff in mind, but not sure it's minimalistic enough for your use case.
Dele (Mobile)has left
Dele (Mobile)has joined
COM8
Holger: dxmpp looks also interresting. Thanks.
Dele (Mobile)has left
Dele (Mobile)has joined
eevvoorhas joined
lskdjfhas joined
adityaborikarhas joined
kokonoehas left
kokonoehas joined
lskdjfhas left
ajhas left
lskdjfhas joined
Dele (Mobile)has left
xnamedhas left
Dele (Mobile)has joined
Steve Killehas joined
ajhas joined
Nekithas left
jubalhhas joined
Dele (Mobile)has left
Dele (Mobile)has joined
Nekithas joined
jubalhhas left
jubalhhas joined
Dele (Mobile)has left
Nekithas left
Dele (Mobile)has joined
adityaborikarhas left
Nekithas joined
adityaborikarhas joined
jmpmanhas joined
COM8has left
COM8has joined
adityaborikarhas left
jubalhhas left
adityaborikarhas joined
kokonoehas left
kokonoehas joined
pdurbinhas left
Nekithas left
Nekithas joined
Danielhas left
Danielhas joined
Alexhas joined
lskdjfhas left
lskdjfhas joined
mimi89999has joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
jmpmanhas left
COM8has left
COM8has joined
neshtaxmpphas joined
COM8has left
adityaborikarhas left
COM8has joined
adityaborikarhas joined
adityaborikarhas left
adityaborikarhas joined
Alexhas left
Alexhas joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
jmpmanhas joined
pdurbinhas joined
Danielhas left
Danielhas joined
COM8has left
COM8has joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Dele (Mobile)has left
pdurbinhas left
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Dele (Mobile)has joined
Dele (Mobile)has left
j.rhas left
j.rhas joined
Steve Killehas left
COM8has left
COM8has joined
Steve Killehas joined
Chobbeshas joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
Steve Killehas left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
Steve Killehas joined
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
Ge0rG
Sigh. Prosody will send a cancel/not-acceptable if you are not in a MUC, Biboumi will send a modify/not-acceptable, and ejabberd will just send a sender-less message into the MUC if you happen to be an admin.
Ge0rG
Consistency, I want you back.
moparisthebest
back?
Ge0rG
Right.
Ge0rG
If I'm reading https://xmpp.org/rfcs/rfc6120.html#stanzas-error-syntax right, `modify` is only about the data, not about your own state.
MattJ
I'd listen to reasoned argument about whether 'cancel' would better be 'modify', but I am currently unconvinced that 'modify' is correct
Ge0rG
MattJ: you can re-try sending the message after joining the MUC
Steve Killehas left
MattJ
True
Ge0rG
I remember a proposal about an application-defined condition of <not-an-occupant> of sorts.
MattJ
For me the semantics of the error types are generally most easily distinguished by the appropriate UI - e.g. 'modify' would re-show whatever dialog a user submitted that caused an action
MattJ
In this case I guess just the input box
Ge0rG
This feels slightly related to cancel/recipient-unavailable that mod_smacks sends when the session dies.
Ge0rG
MattJ: I recently added logic to yaxim to mark the message as "not yet sent" and to rejoin the MUC in those cases.
Ge0rG
but only on cancel/not-acceptable, not on modify
lskdjfhas left
lskdjfhas joined
Ge0rG
maybe Holger knows the right error bounce if you send a message while not being in an ejabberd MUC?
Steve Killehas joined
Ge0rG
Also, the RFC has to say: 'The intended recipient is temporarily unavailable, undergoing maintenance, etc.; the associated error type SHOULD be "wait".'
COM8has joined
Ge0rG
MattJ: the RFC also proposes "modify" for not-acceptable.
Nekithas left
Nekithas joined
larmahas left
larmahas joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
alameyohas left
alameyohas joined
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
jubalhhas joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
alameyohas left
COM8has left
COM8has joined
pdurbinhas joined
COM8has left
COM8has joined
COM8has left
COM8has joined
COM8has left
COM8has joined
adityaborikarhas left
eevvoorhas left
alameyohas joined
COM8has left
COM8has joined
adityaborikarhas joined
COM8has left
COM8has joined
Holger
Ge0rG: Yes ejabberd returns modify/not-acceptable (as per the spec).
pdurbinhas left
Ge0rG
MattJ: ^
Ge0rG
Holger: it's only a SHOULD in the spec.
MattJ
If we deviate from the spec we can certainly fix that
Ge0rG
And modifying the message _data_ won't fix the issue
MattJ
I disagree with most cases of "only a SHOULD"
alameyohas left
alameyohas joined
Holger
Ge0rG: I'm slowly getting used to having to justify why on earth ejabberd adheres to SHOULDs :-)
Kev
Question: Servers are expected to validate stanza syntax for stanzas they route, but does anyone actually extend that to doing the xml:lang rule checking for duplicate bodies etc.?
Ge0rG
Holger: not long ago I violently complained about ejabberd implementing a MAY.
Nekithas left
COM8has left
Nekithas joined
jubalhhas left
alameyohas left
Holger
I do remember :-)
Holger
Kev: ejabberd doesn't, FWIW. (It only checks the validity of the xml:lang value itself.)
Kev
Ta.
jonas’
how about auth/not-acceptable, Ge0rG? :D
Ge0rG
jonas’: is that a serious proposal? 😜
jonas’
Ge0rG, partly
Ge0rG
jonas’: you could submit a PR to 0045 with the new custom error condition.
jonas’
I could indeed
Ge0rG
jonas’: will you?
jonas’
not today
ajhas left
jonas’
I have an aioxmpp release to make
andrey.ghas left
alameyohas joined
adityaborikarhas left
Alexhas left
curenhas joined
adityaborikarhas joined
Alexhas joined
alameyohas left
alameyohas joined
jmpmanhas left
adityaborikarhas left
adityaborikarhas joined
COM8has joined
COM8has left
COM8has joined
Allohas left
Ge0rG
Technically, a message could also be rejected by a MUC for an actual policy violation, right?
Ge0rG
It would be modify/not-acceptable in that case.
Ge0rG
So I think cancel/not-acceptable is a cleaner way of signalling "you are not in the MUC".
Ge0rG
But less clean than cancel/custom-condition/not-an-occupant
MattJ
+1
Zash
Was it MattJ who said type=auth made sense?
MattJ
I don't think so
adityaborikarhas left
adityaborikarhas joined
Ge0rG
it was jonas’ and it wasn't very serious.
lumihas joined
Zash
Well if you consider a join to be almost like auth if you squint the right way
Ge0rG
Maybe we really just need MUC-Push
jonas’
ITYM MIX
Ge0rG
Yeah, let's reinvent all of our protocols without learning from past errors.
jonas’
I got the impression that MIX at least attempts learn from them
Ge0rG
From a subset of them, I'd say.
MattJ
From where I'm looking, it picks a handful of problems with MUC, and fixes them by exchanging them with other design trade-offs
Ge0rG
Mostly with a significantly increased complexity.
sezuanhas left
MattJ
We are solving complex problems
fippo
the problem space is so complex that there is no one-size-fits-all solution
MattJ
Agreed
fippo
(what mattj said...)
Ge0rG
fippo: right. And forcing all the problems into one solution has proven to end up badly in the past.
Daniel
i find MIX to be easier than MUC with the shit loads of hacks you need to implement to make it bearable
Ge0rG
Daniel: only because you don't know yet the shitload of hacks you need to make MIX bearable
Zash
Wait a decade and say that again
Daniel
Ge0rG, well mix is not stable yet so we could fix them before they become hacks
Zash
Requirements change. Hacks accumulate.
adityaborikarhas left
Ge0rG
Daniel: adding MIX rooms to your roster is already a huge hack.
Ge0rG
proxy JIDs... another hack
Ge0rG
handling of intermittent s2s failures: a hack waiting to happen
Daniel
well we decided to not do that
Daniel
putting it in the roster
adityaborikarhas joined
Daniel
the xep just doesn’t know that yet
Ge0rG
oh, where did I put my "told you so" stamp?
Steve Killehas left
kokonoehas left
Daniel
what part?
Ge0rG
MIX has all the signs of "design by committee"
Zash
MUC doesn't?
Ge0rG
Daniel: the MIX-in-roster part
Daniel
that we are going to decide not to do that?
Ge0rG
Zash: hm..
Ge0rG
Daniel: that it's a very dumb idea.
Daniel
yes; that's why we decided to get rid of it
Ge0rG
When did you? And who's "we" anyway?
davidhas left
davidhas joined
Ge0rG
ah, Summit
Steve Killehas joined
kokonoehas joined
COM8has left
Ge0rG
Heh, my first opposition to MIX in Roster was three years and two days ago.
Zash
Delayed happy opposition day!
Ge0rG
I'm not sure whether to be glad or sad.
COM8has joined
pdurbinhas joined
COM8has left
COM8has joined
jonas’
hm
pdurbinhas left
COM8has left
jonas’
It was brought to my attention (as author of XEP-0414) that the section "Analysis of [Hash function use in] Existing XMPP Extensions" was lost in the split of XEP-0300 and XEP-0414
jonas’
I am inclined to remove the (dangling) reference to that section from XEP-414 entirely
jonas’
but I could link it to an older version of XEP-0300 instead
jonas’
does anyone here happen to have a strong opinion on that one?
COM8has joined
Wojtekhas joined
COM8has left
Wojtekhas left
jonas’
https://github.com/xsf/xeps/pull/811
Zash
No strong opinions here. Maybe a "hmm, not sure" from me.
j.rhas left
j.rhas joined
lovetoxhas joined
curenhas left
Lancehas joined
lovetoxhas left
j.rhas left
j.rhas joined
j.rhas left
adityaborikarhas left
lovetoxhas joined
mr.fisterhas joined
Danielhas left
Danielhas joined
Chobbeshas left
Chobbeshas joined
jubalhhas joined
Danielhas left
jonas’
those who have implemented XEP-0027 (Current Jabber OpenPGP Usage): my reading of the XEP indicates that messages are either signed or encrypted, but never both
jonas’
this doesn’t make sense to me
jonas’
but the XEP lacks a writeup on how an signed+encrypted message would look like
ralphm
You can just have both elements I think.
ralphm
In any case you only encrypt/sign the body/status.
jonas’
but it’s not specified whether you sign or encrypt first
Yagizahas left
jonas’
it’s not specified whether the raw or the armored encrypted output is signed (if encrypt-then-sign is used)
ralphm
Yeah, maybe I'm wrong: “It does not enable both signing and encryption of a stanza, only signing of the presence status and encryption of the message body.”
jonas’
that’s kind of meh
jonas’
is it really how it’s deployed in the wild?
ralphm
I think the general opinion of it isn't high.
jonas’
it seems to be the way how openpgp is implemented nowadays though
there is a reason to encrypt but not sign, repudiation, ie "what? I didn't send that and you can't prove that I did!!!!"
moparisthebest
but there is also value in encrypt + sign if you don't need that property
Danielhas joined
j.rhas joined
flow
I am always suprised that xep27 is still gets implemented given the amount of serious issues it has
jonas’
(context why I’m asking: feature request for xep-0027 support against aioxmpp)
Ge0rG
jonas’: sometimes it's best to reject feature requests.
jonas’
sometimes, but then again, we’d just provide the schema declarations anyways
jonas’
e2ee implementation is for now out of scope for aioxmpp
jubalhhas left
moparisthebest
flow, like what?
moparisthebest
I mean it's basically the same as encrypted but not signed email, it can be useful, you just have to know what you are getting
flow
moparisthebest, like the ones mentioned at https://xmpp.org/extensions/xep-0027.html#security (and there are probably more)
pdurbinhas joined
moparisthebest
those aren't really "security issues" as such though
flow
and "it can be useful" is probably true, but I'd argue most xep27 users, would expect signed and encrypted messages
flow
the encrypt only use case is rarely useful
Zash
jonas’, this be why '27 is discouraged and OX is a thing I believe
moparisthebest
for example I used to have my various servers send me alert/cronjob emails etc pgp encrypted, and then I switched to xep27 xmpp messages, same (actually slightly better) security properties
moparisthebest
but yea if users think they are getting something else, that's their problem
Lancehas left
Ge0rG
moparisthebest: that doesn't sound like you had a requirement to not sign.
Nekithas left
moparisthebest
other than I didn't generate PGP keys for my servers no
flow
well it was signed before, so it is true that is not a step back. But if your use case is human-to-human interaction, then "encrypt only" is not what you ever want to do with OpenPGP
flow
*wasn't signed before
jonas’
FWIW, I’m going to tack:
.. warning::
Please see the security considerations of :xep:`27` before making use
of this protocol. Consider implementation of :xep:`373` instead.
on all the things touching XEP-0027 in aioxmpp
jonas’
flow, I have in the past intentionally sent unsigned but encrypted emails
jonas’
but those are very *very* rare cases
jonas’
probably less than five since I started to use gpg
jonas’
and I don’t think it’s the default in any way, and I *do* think that an E2EE protocol which does not support signing of messages *at all* is definitely a prolbem
flow
I can't imagine that the average joe user would want to send unsigned but encrypted mails
jonas’
true
jonas’
me neither
flow
jonas’, what was your intention sending unsigned but encrypted?
Average joe actually doesn't think about encryption at all.
moparisthebest
though I'd accept an argument they should just use OTR instead
pdurbinhas left
jonas’
flow, I made statements which I wasn’t sure I wanted to have signed with my public identity. ✏
Ge0rG
moparisthebest: I'm sure they could just create a throw away key
flow
moparisthebest, anti govt activists shouldn't use e-mail (and probably xmpp) at all for their communication
flow
jonas’, hmm, I don't know the exact case, but that is usually a sign to sleep over the mail another day until you send it ;)
jonas’
flow, I had done that step already
valohas left
j.rhas left
valohas joined
Danielhas left
Danielhas joined
andrey.ghas joined
waqashas joined
jmpmanhas joined
lskdjfhas left
j.rhas joined
larmahas left
j.rhas left
j.rhas joined
eevvoorhas joined
Danielhas left
larmahas joined
lskdjfhas joined
COM8has joined
Chobbeshas left
Chobbeshas joined
COM8has left
COM8has joined
Chobbeshas left
COM8has left
COM8has joined
COM8has left
Lancehas joined
Danielhas joined
Nekithas joined
archas left
archas joined
Lancehas left
Chobbeshas joined
waqashas left
COM8has joined
Wojtekhas joined
Wojtekhas left
COM8has left
pdurbinhas joined
pdurbinhas left
lovetox_has joined
j.rhas left
jubalhhas joined
pep.
Is memberbot offline?
pep.
Ah it's fine now
neshtaxmpphas left
j.rhas joined
pep.
https://wiki.xmpp.org/web/Jonathan_Siegle_Application_2019 Is he around here somewhere? I've never actually heard of him, didn't even know he was running xsf machines
j.rhas left
pep.
(or maybe it's just that I don't know the realname)