I find the world map comparision especially interesting. Germany appears to have a very high search-interest in Matrix
adiaholichas left
adiaholichas joined
zukzukhas left
sonnyhas left
sonnyhas joined
jonas’
probably because we love the movie
sonnyhas left
sonnyhas joined
flow
what's a little bit sad is that the search interest for xmpp decreased by 50% in the last 5 years
flow
jonas’, if only they made a sequel of that movie
jonas’
flow, if only
Ge0rG
aren't they?
jonas’unobstrusively pulls out a wrench
sonnyhas left
betahas left
sonnyhas joined
betahas joined
eevvoorhas joined
pep.
There's a Matrix 4 coming
pep.
https://www.imdb.com/title/tt10838180/
jonas’
different director and writer. could be less terrible.
Zash
ITYM Matrix 2
mukt2has joined
krauqhas joined
Ge0rG
ITYM Synapse 1.8.0
pep.
Synapse, Matrix, it's all the same
mukt2has left
larmahas left
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
larmahas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Nekithas left
mukt2has joined
Lancehas left
goffihas left
strypeyhas joined
emushas left
Lancehas joined
lskdjfhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Dele (Mobile)has joined
Lancehas left
strypeyhas left
mukt2has left
sonnyhas left
lorddavidiiihas left
lorddavidiiihas joined
Lancehas joined
goffihas joined
Shellhas joined
sonnyhas joined
emushas joined
ralphm
jonas’, what do you mean different writer?
pdurbinhas left
Lancehas left
betahas left
sonnyhas left
mukt2has joined
sonnyhas joined
Wojtekhas joined
sonnyhas left
sonnyhas joined
larmahas left
Shellhas left
sonnyhas left
Shellhas joined
marchas joined
larmahas joined
betahas joined
alameyohas left
alameyohas joined
mukt2has left
Shellhas left
mukt2has joined
sonnyhas joined
strypeyhas joined
strypeyhas left
Zash
Hm, going here didn't give me what I hoped for: https://xmpp.org/rfcs/
Maxhas left
Maxhas joined
marchas left
marchas joined
larmahas left
MattJ
I always go there, it's handy
larmahas joined
Zash
Was looking for RFC 7712 tho
jonas’
but the RFCs are rendered terribly :-X
sonnyhas left
betahas left
Zash
Not that bad IMO
Alexhas left
jonas’
yeah I know it’s an unpopular opinion of mine, hence the :-X
Zash
Could be better
jonas’
sure, for example the official IETF html rendering✎
jonas’
sure, for example: https://tools.ietf.org/html/rfc6120 ✏
Zash
This is kinda nice tho: https://www.rfc-editor.org/rfc/rfc8700.html
jonas’
oh that’s true
jonas’
font could be slightly larger
jonas’
reminds me of the XEP renderings
sonnyhas joined
Alexhas joined
betahas joined
sonnyhas left
mukt2has left
betahas left
mukt2has joined
betahas joined
Lancehas joined
pdurbinhas joined
pdurbinhas left
j.rhas left
j.rhas joined
sonnyhas joined
Lancehas left
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
mukt2has left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
mukt2has joined
lorddavidiiihas left
sonnyhas left
sonnyhas joined
lorddavidiiihas joined
eevvoorhas left
eevvoorhas joined
eevvoorhas left
Ge0rG
jonas’ [13:17]:
> sure, for example: https://tools.ietf.org/html/rfc6120
That's the worst skeuomorph in the history of the Internet
Ge0rG
The XSF renderings are plain awesome in comparison
eevvoorhas joined
Shellhas joined
Ge0rG
And rfc editor isn't rendering any old RFCs in the nice html, so only the 50 years one?
Ge0rG
The mandatory page breaks make my eyes bleed, and I don't even want to try to read that on an e book reader.
Zash
Only a few very recent ones
Ge0rG
And I'm sure they actually have semantically structured source code, so this is absolutely self inflicted
Steve Kille
There was a LOT of argument that ASCII is the only thing everone can handle.
Ge0rG
Steve Kille: I'm not opposed to having an ASCII version, not even in 2020. What infuriates me is what they call "html" rendering.
jonas’
Ge0rG, it’s still better than the kilometers of line length on the XSF rendering
Ge0rG
jonas’: you are doing Browser wrong.
jonas’
no, the XSF rendering is doing typography wrong
betahas left
Ge0rG
Whereas the official rendering is also doing accessibility and readability wrong.
j.rhas left
betahas joined
Shellhas left
Shellhas joined
Ge0rG
> If only a web browser is available, the PDF rendering of an RFC is often the better choice than the HTML version.
> Starting with RFC 8651, RFCs are published as XML files [..]
Steve Kille
should have been done a LONG time ago
Zash
Like XEPs! 🙂
Ge0rG
it only has sustained for so long because of bearded old men (and I mean men who are both more bearded and older than me)
ralphm
[citation needed]
Ge0rG
🤷
j.rhas joined
j.rhas left
j.rhas joined
Shellhas left
Shellhas joined
ralphm
Come on, you can throw around general dismissive statements like this, but at least provide _something_ to back it up. A few months ago there was a discussion on us using XML as the format for XEPs, and I contemplated the impact on moving to, e.g. ReST or some Markdown dialect, but such an effort is not trivial by any means. The IETF is so much more bigger in reach, older, etc. that I am not surprised it took a while to come up with a plan forward. RFC 7990 provides some more insight.
mathijshas left
mathijshas joined
Zash
ralphm: Fun fact: I have mostly working scripts for translating XEP XML to and from Markdown
ralphm
E.g. “In order to respond to concerns regarding responses to subpoenas and to understand the legal requirements, advice was requested from the IETF Trust legal team regarding what format or formats would be considered reasonable when responding to a subpoena request for an RFC.”
jonas’
A subpoena request for a thing which is public?
stpeterhas joined
ralphm
This is about subpoena's where the response would need to include an RFC.
ralphm
jonas’ simply sending a URL is probably not sufficient.
Shellhas left
Shellhas joined
stpeterhas left
Ge0rG
ralphm: I'm not involved in the RFC process, and maybe my impression that any RFC has a semantic source code and could be trivially rendered the same way as we did for https://xmpp.org/rfcs/rfc6120.html is wrong. However, the ASCII paginated format is not in wide use in the IT industry for over thirty years now.
neshtaxmpphas left
Ge0rG
And I'm sure people can come up with a saner mechanism in much less than thirty years, if they actually see a need.
ralphm
Up until this RFC, the canonical version is been plain-text, in that paginated formatting.
Ge0rG
Probably even a mechanims to retro-fit the old ASCII submissions into a new format.
ralphm
And it is not that people didn't use XML as the actual source format, but this change lifts a lot of restrictions.
Ge0rG
RFC8651 has been published last October.
goffihas left
ralphm
Right, its HTML rendering is based on the XML file, not on the plain text.
Ge0rG
Yeah, it's the first one.
Ge0rG
But as I said, this has taken thirty years.
Ge0rG
The printer that I got with my first computer, purchased used in 1993, was able to render proper typography, given the right software and drivers.
betahas left
ralphm
It would be awesome if older RFCs that have been crafted in an XML format, like I believe all XMPP related ones authored by stpeter, could be re-processed, but I'm not sure if their processes allow this to be done retroactively.
Ge0rG
OTOH, I can't read most RFCs on my smartphone screen because the fixed-width fixed-page-width mandatory-line-breaks format is just bonkers.
Ge0rG
ralphm: given sufficient motivation, processes can be changed.
ralphm
Ge0rG, sure, and there are histerical raisins for this.
ralphm
And they did, eventually.
Ge0rG
ralphm: maybe because the IETF members realized that they are getting older and that their eyes are getting worse, so they can't read the RFCs any more.
ralphm
We can complain about the speed of it, but I think that's too easy.
ralphm
And not a very productive attitude.
debaclehas joined
edhelas
did some of you already played with http://sylkserver.com/ ?
Ge0rG
ralphm: I can't fix _all_ the things.
edhelas
does it act as a nice XMPP-SIP bridge, at least for IM ?
ralphm
Ge0rG, I think the bar I set was lower than _all_ :-D
ralphm
edhelas, SIMPLE is still a thing?
edhelas
yup
ralphm
wow
Shellhas left
edhelas
I'm currently working at the company behind Linphone and they are developping IM features within their clients :)
I installed their Android app the other day, it was the only one I could get to work reliably
lorddavidiiihas joined
MattJ
For SIP, not SIMPLE :)
edhelas
i'm looking for SIP-XMPP gateways
Ge0rG
ralphm: well yes, but I read your statement as an equivalent to "provide patches"
Steve Kille
do you mean SIMPLE-XMPP?
edhelas
ah it's not SIMPLE based actually
edhelas
my bad
emushas left
lorddavidiiihas left
lorddavidiiihas joined
UṣLhas left
Shellhas joined
krauqhas left
ralphm
Ge0rG, no my statement is more "we can all do a lot better than making dismissive or facetious comments about the work of others."
ralphm
edhelas, what it is then?
Ge0rG
ralphm: well, that's true
lorddavidiiihas left
lorddavidiiihas joined
Shellhas left
Lancehas joined
lorddavidiiihas left
pdurbinhas joined
Nekithas joined
lorddavidiiihas joined
ralphm
By the way, I think that https://xmpp.org/rfcs/rfc6120.xml is using the xml2rfc v1 format. I'm sure it would be relatively easy to have that processed as the newer XEPs are.
ralphm, is that exceptional or do most messages contain that kind of reactions?
ralphm
No this is not common. The message was meant for a different channel, with a smaller audience, but funny in the context of this channel, which is appropriately named has virtual all employees in it.
ralphm
virtually
sonnyhas left
ralphm
I do think, however, that we should expect exceptions like this to be good test case for reactions in XMPP, and particularly for how we handle this in MAM context.
edhelas
XEP-xxxx: Kindly ask XMPP users to not send too much Reactions in chats (Informational
ralphm
heh
edhelas
or we go full ascii ¯\_(ツ)_/¯
pep.
This is not ascii
dwd
What I find interesting is that there are very few Unicode reactions there; they're mostly custom images.
pep.
(-̀◞८̯◟-́)
edhelas
╯°□°)╯︵ ┻━┻
Zash
So limiting reactions to emoji is meh
pep.
┗(•̀へ •́ ╮ )
pep.
(people have lots of imagination)
pep.
XEP-XXXX: Reactions + bob?
Wojtekhas left
dwd
Also I quite like the notion of having sequences like ╯°□°)╯︵ ┻━┻ as reactions.
pep.
I'm curious if other solutions allow that. I don't think I've seen it in Mattermost or Slack
Zash
And 'wat'
pep.
щ(ºДºщ)
pep.
("Why?!")
sonnyhas joined
Wojtekhas joined
mukt2has left
dwd
pep., No, I haven't either, but it seems potentially useful.
pep.
well it's doable in the current spec. "Just" include that in <reaction/>
dwd
Oooh. Polls. Those'd work as fastenings with MAMFC very easily.
mukt2has joined
Lancehas joined
betahas left
pep.
dwd, for polls I do want the whole history of who voted what, and if they changed their votes etc. :x
pep.
Reactions might be ok for quick polls, but for more serious stuff you probably don't want that
pep.
You want the possibility to comment alongside your vote, at least. (that is, your message referencing your action of voting, or sth..)
dwd
The moment you want anonymous polls it gets a bit harder, true.
betahas joined
pep.
Right also that
j.rhas left
j.rhas joined
stpeterhas joined
emushas joined
Lancehas left
ralphm
Yeah, simple polls are pretty much the same as reactions. And indeed, in all Slacks I've been in, most reactions were using Slackmoji (custom emoji). That's also why I used that in my blog post.
lorddavidiiihas left
lorddavidiiihas joined
adiaholichas left
debaclehas left
goffihas joined
mathijshas left
mathijshas joined
j.rhas left
adiaholichas joined
pep.
To come back to the OMEMO talk (from council@): Note that I'm not opposing getting rid of OMEMO.
ralphm
larma: regarding the discussion on OMEMO in council@ just now. If the XEP is moved to Proposed, a Last Call process will start. During this time, people can provide their comments. Then Council can decide to do one out of three things: 1) move back to Experimental, judging it not ready to move forward, and allowing the author or others to amend it to their instructions (e.g. fix the license issue), 2) reject it definitively, 3) accept.
pep.
Just that we don't have anything to replace it.
pep.
And I hate the message that this is sending
pep.
"We don't care about e2ee"
jonas’
context for the above: https://logs.xmpp.org/council/2020-01-08#2020-01-08-40325e18d4aac62b
taohas joined
Maxhas left
jonas’
pep., though Daniel proposed to write a blogpost which explains the rationale and why this is a good thing actually.
pep.
Is it a good thing
ralphm
pep. we can control the narritive ourselves. E.g. by launching the SIG and announcing an effort to work within the IETF to have an MLS spec for XMPP.
Maxhas joined
jonas’
and I think we can do things to make this blog post discoverable, including but not limited to:
- mention it in the editor notification
- mention it in the council decision
- link it from the top of the XEP
jonas’
pep., yes, it is a good thing for implementation freedom
pep.
And what in the meantime? "yeah well you can use that deprecated-or-rejected XEP, because everybody else use it"
pep.
"yay standards"
ralphm
pep., this is nothing new
pep.
To me the XSF is shooting itself in the foot
jonas’
pep., yes, and no. Push OX forward, push FSE+OX forward, and if you have to, use OMEMO which is why I want to keep this XEP in place, albeit frozen in stasis.
jonas’
or even push SEX forward, with a slightly less awful name
pep.
These are not OMEMO replacements
ralphm
People have used non-SASL authentication for ages after we obsoleted it.
pep.
they're perfectly valid encryption mechanisms for sure, but they don't do PFS (not that I'm arguing in favor of PFS)
jonas’
pep., I’d also argue that OMEMO is not a good solution
Shellhas joined
jonas’
and the replacements I mentioned are all better than OMEMO for the general userbase
pep.
jonas’, that's another debate
pep.
I also agree
jonas’
so this is another reason why this is a good thing™
Zash
OMEMO is popular. Popularity does not equal quality.
j.rhas joined
jonas’
it encourages the deployment of (for some metric) better alternatives
pep.
I also agree getting rid of PFS for the masses is a good thing. But that's not the debate at hand
ralphm
pep. and I think everybody agrees that the E2EE situation in XMPP has been an issue for a very long time. This is why I do like the proposal to form a SIG.
larma
ralphm, the current best thing we have is OMEMO. It's not good, but it's the best we have
ralphm
larma, yes, and it doesn't meet our objectives, so that's terrible.
larma
Which objective?
ralphm
larma: #4 of XEP-0001
jonas’
larma, https://xmpp.org/extensions/xep-0001.html#objectives number 4
pep.
"good is the enemy of perfect"?
larma
It doesn't strictly violate it either
larma
it just lacks documentation
jonas’
larma, I think it does
jonas’
even if it is strictly legal, the ambiguity of the situation is encumberence enough
dwd
pep., Not good is the enemy of good, too.
larma
what ambiguity?
jonas’
larma, whether it is a legal thing to do without using the GPL
ralphm
larma: if it is just lacking documentation, the onus is on whoever wants to progress the XEP to resolve this before it can move forward in our process.
jonas’
where "it" is "implementing and using the Signal protocol"
pep.
dwd, what's the actual reason behind this move?
Nekithas left
dwd
pep., I've explained that several times.
larma
well "Signal" is probably a trademark and thus can't be used in the XEP, I agree
larma
but that's again a documentation issue
jonas’
larma, I’m talking about the protocol, not the name
dwd
pep., Unless by "actual" you're trying to imply I'm not really saying.
larma
the cryptographic protocol is pretty well specified in their public domain documents
pep.
That it can't be implemented in proprietary products etc.(?)
ralphm
larma, there have been efforts to reimplement the protocol in a library for other languages that the official libsignal, and they were considered derivative works, and thus subject to the GPL.
ralphm
I think there even was a library that changed licenses for this.
jonas’
pep., that it can’t be implemented *in non-GPL products
ralphm
pep., and yes, the XSF expressly supports implementations open or closed alike.
pep.
jonas’, sure. I doubt this is really in issue in practice though.
jonas’
pep., that’s not the point.
jonas’
it violates objective 4
larma
well if you create a derivative work of libsignal it has to be under GPL, but I doubt that you have to do so
dwd
pep., Why do you think that's not an issue?
jonas’
whether it’s a prolbem in practice because everyone who does OMEMO also happens to be okay with the GPL is a different issue
ralphm
Companies and proprietary implementations of our open protocols are not a bad thing, and explicitly part of the XSF's DNA.
pep.
That I can see indeed
ralphm
pep., I don't understand why you want to argue against this.
flow
I feels like the discussion around rejecting xep384 distracts from the really important question: Why wasn't the pull request that helps making xep384 independent of the libsignal wire protocol and move towards the open standard double ratched implementation merged?
jonas’
flow, URL?
jonas’
I guess the log in the PR would explain the reasons
pep.
I don't especially agree, but that debate is different from the points I'm bringing forward with OMEMO
pep.
ralphm, ^
flow
jonas’, no it doesn't, editor closed it
dwd
pep., Put it this way - if OMEMO genuinely cannot be implemented without a GPL library, should we kill it?
jonas’
flow, URL please then?
jonas’
that was probably me, and I might know more
jonas’
(when I see the PR)
flow
jonas’, https://github.com/xsf/xeps/pull/460
larma
dwd, I personally agree to that
Half-Shothas left
pep.
dwd, that's not my point in this debate. I'm not answering this question
jonas’
pep., but that’s the *reason* for this debate
ralphm
pep., except it isn't. Because if the argument is not clearly worded, it might taken as a Board stance.
jonas’
flow, ah, the reason is right there: inactivity.
jonas’
I didn’t get a reply from the author in weeks
flow
jonas’, of course the question is "why went the author silent"
pep.
I'm saying "it has been accepted in experimental, deal with it as long as it's not proposed" (and the author hasn't, for good reasons)
jonas’
flow, that I cannot anwser
pep.
We are sending a message that I don't want to send
flow
and there is a larger backstory to that behind what you can read from the comments in the PR
ralphm
pep., and I want to clearly communicate to everyone in our community that we definitely consider companies and proprietary implementations as part of our community.
dwd
pep., One problem here is that it forces other projects to send the same message.
pep.
Which projects?
Daniel
flow, that is an interesting question; which i would like to slightly repharse to "why isn’t the work on 'OMEMO 2.0'" moving faster? (i think the actual PR that was on the table had some minor problems; but it doesn’t really matter because some members of the 'OMEMO community' have working drafts for 'OMEMO 2' on their hard drives)
dwd
pep., Look at, for example, the OMEMO ticket against Swift.
dwd
pep., There's people there saying that the Swift leadership doesn't care about E2EE, which is incorrect - but they cannot implement OMEMO (or feel they cannot).
pep.
So you need to kill it as long as we don't have a replacement. Like it's become a mission right now?
Daniel
so why don’t we have omemo 2? - i think the answer to that is: omemo 2 is not backward compatible and for the vast amount of stakeholders (=people who actually do the work) omemo 1.0 is good enough; despite problems
pep.
Swift can very well implement OX
pep.
Gajim also supports OX. Swift can also drive the adoption around OX
pep.
I'm sure others would implement it
jonas’
pep., the problem (the XEP violates a criterium for XEPs) was spotted, the problem is known, and it needs to be fixed now.
pep.
(I would)
Daniel
the combination of not being able to solve backward compat and good enough lessens the incentives to work on 'omemo 2'
jonas’
if we want to further represent our objectives
flow
Daniel, why isn't omemo2 backwards compatible? Couldn't clients just use the same key material and crypto primitives with OMEMO1 and OMEMO2?
jonas’
it sohuld never have come this far, but here we are
jonas’
flow, it won’t be compatible on the wire by definition, that’s incompatibility enough
Daniel
it's probably not backward compat in a non-gpl way
flow
jonas’, not in my book
dwd
pep., Are you arguing, then, that since OMEMO has a viable replacement it's OK to get rid of it?
jonas’
flow, in practice it is
jonas’
OMEMO1 clients won’t be able to read OMEMO2 messages
pep.
dwd, when, not since
Daniel
hardcoded strings and unspeced protobuf
flow
jonas’, sure the XML element definition will be different, but the keys could be the same
jonas’
it’s "This message is OMEMO encrypted ..." all over again
Daniel
that may or may not be gpl
dwd
pep., Because you cannot argue that Swift can just implement OX unless you believe that OX is a replacement.
Daniel
plus if we are going to introdcue breaking changes we also might want to fix other things
jonas’
something second system syndrome
pep.
dwd, replacement as in "widely used encryption mechanism". It's not exactly a replacement for OMEMO in the sense that it doesn't have Forward Secracy (but I'm of those that say that most don't need it)
flow
jonas’> OMEMO1 clients won’t be able to read OMEMO2 messages
sure but there is nothing one can do about it
jonas’
flow, and that’s why people don’t want to move from OMEMO1
larma
Just my feelings to this whole story: nobody wants to implement the full protocol. Mostly because crypto is hard to get right and thus implementing it is timely and expensive. Those that are GPL-compliant are mostly fine with using libsignal (or creating a derivative thereof), but those that aren't GPL-compliant cannot and thus are in the situation that the feature of implementing OMEMO is requested but can't be realized. OMEMO puts non-GPL-compliant implementations at a financial disadvantage.
Daniel
jonas’, well yes and no. there are some relatively low hanging fruit that could be fixed
Daniel
but not backwards compatible
ralphm
A lot of this is a rehash of earlier discussions, but we never made it explicit that the XEP in its current form is not acceptable to our process. Also see remko's efforts in https://github.com/xsf/xeps/pull/463
Daniel
ralphm, i think nobody is denying that it is a shitty xep
jonas’
Daniel, cp xep-0384.xml inbox/daniels-omemo2.xml and get started? ;)
flow
jonas’> flow, and that’s why people don’t want to move from OMEMO1
IMHO OMEMO1 has enough issues to be incentived to move away from it, but YMMV
Daniel
jonas’, not _my_ harddrive 🙂
ralphm
larma: and I also think that this is *the* reason why accepting OMEMO, even as historical or informational, doesn't send the right message from the XSF.
jonas’
flow, IMO, OMEMO can die in a housefire, but that’s just me. I think we’re quite alone on that island ;)
ralphm
jonas’ not at all
flow
jonas’, It's fine if you don't care about a XEP if you don't actively fight it
pep.
larma, to this specific comment I can say "I'm fine with it. That's the whole point of GPL." (independently of OMEMO being a XEP) :X
jonas’
flow, I don’t "fight" it for those reasons.
jonas’
flow, I fight it because I think that ralphm and dwd are right.
Half-Shothas joined
jonas’
my fight against OMEMO itself mostly consists of "No omemo here" replies to messages which are OMEMO encrypted *shrug*
flow
ok, let me specifiy this "if you don't actively fight it's development"
ralphm
pep., yes, the choice of GPL is intentional, and detrimental to open protocol development.
pdurbinhas joined
ralphm
(because there is no protocol spec)
jonas’
flow, I’m just trying to make a point that for many people, OMEMO1 is just good enough, even if there are many reasons why it should not.
jonas’
flow, thus supporting your YMMV
larma
ralphm, is it against the XSF objective 4 if implementing a protocol using a GPL library is cheaper than implementing it without?
jonas’
larma, no, but the question here is whether it is legally POSSIBLE to implement it without the GPL library.
flow
that ^
jonas’
and this question is not answered without a lawyer and probably a court case. and this is why this is an encumberence, even if it IS legally possible to do so
ralphm
larma, using a GPL library is fine. Having the GPL library being the only source of information to implement it independently, without it being a derivative work and thus subject to the GPL *is*
larma
jonas’, you could argue the same for *every* XEP
jonas’
larma, no
jonas’
XEPs which fully describe the protocol can clearly be implemented non-GPL
jonas’
because they are under XSF IPR
jonas’
XEPs which rely solely on other open standards (e.g. RFCs)are the same
larma
jonas’, sure, so if I just put all the required stuff in the XEP what happens then?
jonas’
larma, then you’re liable
jonas’
if that’s under GPL and you passed it to the XSF while having the IPR signed
jonas’
you will be liable for that when moxie sues an implementation
jonas’
the implementation can point at the XEP, the XSF can point at you
dwd
jonas’, Actually I suspect the XSF might be liable.
Zash
Isn't that how cleanroom implementations are done? One team looks at gpl code and writes docs.
jonas’
dwd, at this point, probably yes, because we already have publicly stated that we have doubts
flow
"it doesn’t really matter because some members of the 'OMEMO community' have working drafts for 'OMEMO 2' on their hard drives"
It would be great if that development of OMEMO2 wouldn't happen on ppls hard drives but instead in a public repo (with rendered htmls put online somewhere). I don't even say that it has to happen within the XSF
ralphm
dwd: that's an interesting point that might graduate it to Board territory.
flow
Daniel, ^
larma
As mentioned on list, I have no problem with publishing all the protocol details that are missing under a permissive license, I just don't know what exactly is missing
ralphm
So I guess we can point to Daniel.
jonas’
larma, nobody who hasn’t implemented it without libsignal does.
ralphm
(who put in the dependency on libsignal, if I remember correctly)
eevvoorhas left
flow
larma, please do so
pep.
flow, one of the reasons why the SIG is happening I think
jonas’
larma, i.e., to find out, try that
pep.
flow, I also want that, transparency
flow
I think it is easy to find out what is missing. Just add everything that is missing from the XEP
flow
pep., that nice, but you don't have to form a SIG to invite people to collaborate ;)
ralphm
flow this
pep.
Well.. people are what they are
larma
If OMEMO2 is only using a different wire protocol (replacing protobuf with xml) than that should be easy, because the wire protocol is protobuf
pep.
You need to get them motivated to do things
pep.
We're not all paid to do stuff
ralphm
a SIG is not super special. I would also like to point to XEP-0019 for a bit of history of SIGs.
pep.
I've read that one yes
taohas left
Daniel
flow, if it were my harddrive i would
Shellhas left
ralphm
pep., I'm not payed to this stuff, either. Interestingly, commercial entities generally are, and they can't implement OMEMO in its current form for the arguments-discussed-at-length. Moxie at some point said they'd provide a spec, but things were still in flux.
dwd
pep., You know, I'm not sure any of us are paid to do this anymore.
Daniel
however it doesn’t really solve the "we don’t know how to migrate" issue
dwd
Daniel, Well, non-migration between crypto protocols isn't unique to OMEMO.
ralphm
They'll probably remain in flux, so depending on an everchanging library isn't a great place to be, and not having a matching spec is not an acceptable starting point.
flow
Daniel, it appears there is no good solution besides probably a grace period where clients send OMEMO1 and OMEMO2 together
flow
don't ask me how long that period should be
sonnyhas left
dwd
Daniel, And is a particular problem with E2EE in IM. Long talks about that in the MLS WG as well.
flow
OTOH it appears that most OMEMO developers are agile
pep.
flow, at this point I'd start working on MLS rather than having a migration period of "forever" already between OMEMO1 and OMEMO2
mukt2has left
ralphm
pep., great!
pep.
(not me personally)
flow
pep., do ash you like, but I think it is sensible to put effort into OMEMO2
pep.
And another migration period of "forever" between OMEMO2 and MLS
ralphm
pep., (aw)
sonnyhas joined
pep.
ralphm, as funny as it might seem from me arguing about all this, I don't use e2ee very much myself :)
ralphm
I think it would be a worthwhile excercise to see what needs to be done to do MLS in XMPP, compared to potential work on OMEMO.
pep.
I think the migration effort outweights everything
pep.
Debian, RHEL, $things
pep.
In 10 years we're still sending OMEMO1
ralphm
pep., I personally really dislike the way OTR and OMEMO have worked so far, and any solution that has a similar pattern will be vigorously disabled by me.
jonas’
ralphm, I’m curious which aspect you’re talking about, because my experience with OTR was quite pleasant, while OMEMO was terrible.
jonas’, I'm also curious which aspect of OTR you find pleasant
pep.
(compared to OMEMO)
Daniel
and yes being unsure if we even want to solve the migration to omemo 2 or start working on 'something else' is also a hurdle that prevents people from working on omemo 2
dwd
Jr fubhyq nyy hfr EBG13
ralphm
jonas’, I have been using XMPP since 2000, and have seen a lot, using multiple clients simultaneously, and every time somebody tried to send me a message with OTR or OMEMO, I ran into issues of not being able to read it.
pep., I get OMEMO encrypted messages forever just because I have Conversations installed, but 2 out of 3 of my clients don’t support OMEMO, and two out of three never will.
pep.
Ah wait I have a better one now that we have the E2EE API :p
pep.
jonas’, I remember mod_otr in prosody preventing you from sending messages that were not OTR encrypted.
pep.
I don't think that's really better
jonas’
pep., that’s a problem of a server deployment
jonas’
not a general problem of the thing
pep.
But you got to get the green checks
mukt2has joined
pep.
:)
jonas’
pep., missing the point
Zash
jonas’: green checkmarks!!!1!1!eleven
pep.
I don't think OMEMO is worse in this regard tbh
Zash
MUST HAVE GREEN CHECKMARKS AND E2EE!!!!
pep.
That's a policy of the clients. Enabling OTR/OMEMO by default
pep.
Whether you are capable of receiving it or not
Zash
MUST HAVE GREEN CHECKMARKS AND E2EE ENABLED BY DEFAULT!!!
debaclehas joined
pdurbinhas left
ralphm
Additionally, I think that there are features in XMPP that compete with the notion of E2EE and the kinds of protections it provides to the end user. To the point that I'm sure you can always make the argument that e2ee in XMPP remains insufficient to some groups of users.
jonas’
pep., no, the difference is the mechanism of discovery of support
jonas’
the one used by OMEMO is unreliable
jonas’
("are keys published?")
jonas’
the one used by OTR is reliable, barring server intervention ("is the secret whitespace handshake sent?")✎
jonas’
the one used by OTR is reliable, barring server intervention ("is the secret whitespace handshake sent in the message I just got?") ✏
pep.
Ok, on the theory maybe
jonas’
ralphm, agreed
jonas’
pep., in practice.
pep.
In practice clients would probably just enable OTR because what Zash said
jonas’
also, you notice when the OTR handshake fails and don’t blindly send encrypted messages which won’t be readable
jonas’
because OTR has a handshake
krauqhas left
mathijshas left
mathijshas joined
jonas’
pep., "would" -- OTR has been around since forever. There is no "would" here, we can look at the state of what clients are still doing.
calvinhas left
pep.
Ok
jonas’
(or what they did before they dropped support for OTR in favour of OMEMO)
!XSF_Martin
jonas’: A Chatsecure always sent me otr garbage although I had never otr enabled with any client on that jid …
pep.
(There are still new clients getting OTR support fwiw)
jonas’
!XSF_Martin, neat, that’s the first time I hear that. However, that garbage was most certainly not a message you missed.
jonas’
in contrast to OMEMO
mukt2has left
dwd
pep., libotr is LGPL...
pep.
dwd, context?
dwd
> (There are still new clients getting OTR support fwiw)
mathijshas left
mathijshas joined
pep.
I was thinking about a fork of conversations. That also removed OMEMO support iirc
pep.
But I'm sorry I don't understand what you want to say
Zash
pep.: Not all those forks that just did search and replace on everything, including the OMEMO siacs namespace?
dwd
pep., I mean, not only does OTRv3 have a detailed specification including wire format, but it also has a library that's more easily used, license-wise.
pep.
Ah my bad it's not a fork of conversations. I was thinking of https://github.com/coyim/coyim
dwd
?OTRv23?
dwd
Anyone?
dwd
:-)
pep.
dwd, sure. That's not exactly compatible with how we want to use XMPP in the open world (from what I understand), but that's a direction a set of products can take for sure
taohas joined
ralphm
?OTRvTemp?
pep.
(multiple devices anyone?)
mukt2has joined
Tobiashas left
Tobiashas joined
Lancehas joined
krauqhas joined
mukt2has left
mukt2has joined
taohas left
Steve Killehas left
Steve Killehas joined
mathijshas left
mathijshas joined
rion
Are you guys taking about deprecating omemo in favor of otr?
Zash
I don't think so
mukt2has left
Dele (Mobile)has left
mathijshas left
mathijshas joined
dwd
rion, No.
moparisthebest
I think deprecating omemo in favor of $some_future_protocol_that_might_be_better ?
dwd
rion, For two reasons: Firstly, we don't deprecate "in favour of" anything. Secondly, we all agree that OTR is a bit pants.
dwd
rion, That said, there *is* an OTR XEP, and everyone is, I think, confident it can be implemented by anyone.
moparisthebest
when you say "implemented by everyone" are you speaking technically or legally ?
pep.
rion, indeed we're not deprecating in favor of anything..
moparisthebest
because surely omemo and otr are both capable of being implemented by anyone from a technical perspective right?
dwd
I said "implemented by anyone", meaning that anyone *could* implement. There is both technical information available and no licensing restrictions upon it.
moparisthebest
legally, well depending on how licenses are interpreted in a given jurisdiction, or whether encryption is illegal or not, "it depends" for both otr and omemo
moparisthebest
so I guess you are saying the XSF is in the business of interpreting license legality across jurisdictions around the world, which seems insane to me
rion
in Russia any encryption unavailable for deciphering by the government is illegal. But anyway I hope nothing was implemented in vain :)
dwd
moparisthebest, Are you saying the XSF should take the position that all IPR is meaningless?
moparisthebest
there are probably other reasons to do OMEMO differently, I just don't think licensing of any code should be one of them
dwd
moparisthebest, And you are very much in the minority there.
rion
I think those XEPs should have something about availability for government :)
moparisthebest
sure, otherwise it's illegal in russia and probably china, better remove TLS too since not everyone can implement it
mukt2has joined
moparisthebest
/sarcasm (just to be clear :) )
rion
we just need some xeps how to properly implement backdoors on servers
moparisthebest
I do hate how all this looks to an outsider, not just this, but we are in a similar position with a lot of protocols aren't we?
dwd
moparisthebest, No, I don't think so.
moparisthebest
Q: "how can I add color to my messages in XMPP?" A: "well we had xhtml-im and some things implement it, but it's deprecated, one day we might have a good way to do it"
dwd
moparisthebest, Oh, deprecation you mean.
moparisthebest
Q: "how can I do sane group chat in XMPP with mobile etc?" A: "well we have a group chat that doesn't work so well in mobile, but we refuse to improve it, there is a proposal for one that'll probably work good one day but nothing implements it"
moparisthebest
Q: "how can I do e2e in XMPP?" A: "well any of 4 or so ways, the most widely deployed is now deprecated and we might have a replacement one day"
moparisthebest
it's almost a theme isn't it?
dwd
moparisthebest, I've implemented MIX twice. That whole situation frustrates the hell out of me, too.
dwd
moparisthebest, But XHTML-IM... Yeah, I'm not sorry to see that one go.
moparisthebest
it seems like XSF is working/waiting on the *perfect* solution, while everyone else trudges along with *good enough*
dwd
moparisthebest, Also I think I'm probably right if I asserted that OTR is the most widely deployed outside this bubble.
rion
xhtml-im was good. maybe not that good as markdown but good anyway.
moparisthebest
rion, as has been pointed out countless times, we don't have anything resembling a markdown XEP :)
dwd
rion, Yes, except literally every client that implemented it had a security issue relating to it.
moparisthebest
(also markdown doesn't support coloring)
Zash
markdown is a html superset, therefore it also sucks
dwd
moparisthebest, Honestly, does anyone care about colouring? I mean, during the whole discussion I think Ge0rG mentioned it about source-code highlighting in messages, which is pretty niche.
moparisthebest
also I understand the whole xhtml-im thing and even agree with it, just pointing out how all of these things must look to an outsider
rion
dwd: well I filtered it in iris. everything but css styles which made a lot of fun to filter out =)
calvinhas joined
Zash
moparisthebest: everything is terrible
dwd
rion, "fun" is not what I want in security-sensitive code. :-)
moparisthebest
I was trying to decide if I was more frustrated with MUC/MIX or e2e, and I guess it's gotta be MUC/MIX because at least the (deprecated) e2e has deployed running code :)
Zash
So, who wants to cp xep-0071.xml inbox/xhtmlim-but-better.xml ? Link Mauve?
winfriedhas left
winfriedhas joined
rion
I understand that but when on 1st april you inject a style which put a group chat up side down it looks awesome :)
rion
for everyone ))
dwd
moparisthebest, I've argued before that I'm concerned we may have gone in a bad direction with MIX.
winfriedhas left
winfriedhas joined
Link Mauve
Zash, sure.
dwd
moparisthebest, I joke that I've lost two jobs due to MIX, and I'm not entirely exaggerating either.
rion
inbox/xhtmlim-this-time-serous.xml works better ;-)
dwd
We did that joke, I think.
moparisthebest
any better time to try and fix it than now maybe dwd ? :)
dwd
rion, https://xmpp.org/extensions/xep-0402.html
Zash
XHTML-IM 2: Electric Boogaloo
dwd
moparisthebest, Yeah, lots of good times, like when I'm not swamped by both work and taking on too much from fastenings.
flow
dwd, you lost jobs due to MIX?
dwd
flow, As I say, it's something of an exaggeration.
dwd
flow, But my last job fell to pieces in part because of MUC vs MIX, and the difficulty in doing MIX without any client implementations.
j.rhas left
dwd
flow, The other one was more that the project I was working on - with MIX in both client and server - got canned and everyone else left, so eventually I did too.
Shellhas joined
j.rhas joined
dwd
flow, But had MIX been widely deployed in, erm, March last year, I'd probably still have the job I had then.
j.rhas left
flow
I see. And I assume the resources (people, money, bitcoin, …) to implement MIX where not available?
j.rhas joined
mukt2has left
moparisthebest
maybe we should have a new business rule, that if an experimental xep doesn't have a single complete implementation in 7 years it's moved to deprecated/historical or something
mukt2has joined
rion
what if MIX didn't exist and had to be designed again. would it go as an extension to MUC instead of completely separate protocol?
flow
Link Mauve, do you have stats from jabber.fr about the current usage of e2ee in xmpp? something like x% of the messages of the past 30 days where encrypted with y?
flow
https://stats.jabberfr.org/d/000000002/jabberfr?orgId=1&fullscreen&panelId=36&from=now-7d&to=now is not really helpful to get an idea how widespread which encryption scheme is
Link Mauve
flow, I do have stats of that at https://stats.jabberfr.org/
krauqhas left
Link Mauve
Hmm, how do you do queries to Prometheus again?
Link Mauve
flow, seems like out of all of the encryption methods, OTR is by far the most popular.
moparisthebest
rion, the 2 I can pull up immediatly are https://xmpp.org/extensions/inbox/muc-light.html and https://docs.ejabberd.im/developer/xmpp-clients-bots/extensions/muc-sub/
moparisthebest
I think Xabber has their own, can't recall if it was submitted or not
mathijshas left
mathijshas joined
moparisthebest
I could be mistaken here, but I'm under the impression Xabber has put the most thought into "how can I make this work on the trash platform that is iOS", which requires insane measures
Alexhas left
Alexhas joined
rion
> Occupants cannot hide behind nicks. Their real bare JID is always visible to everyone
I like this (no sarcasm)
moparisthebest
have you noticed there are virtually no useable iOS XMPP clients? and that's even just for regular private XMPP, it's worse for MUCs
Alexhas left
Alexhas joined
Daniel
muc/sub is mainly an attempt to fix push with the rest of it being an aftertought that didn’t really felt like anyone before me had implemented it
Daniel
and if you just look at who else has custom shit to fix the push issue tigase is also on the list
rion
> No exchange of any <presence/> stanza inside the room.
online/offline status still has to be somehow reflected
Link Mauve
Hmm, Error executing query: parse error at char 40: range specification must be preceded by a metric selector, but follows a *promql.AggregateExpr instead
Link Mauve
sum(prosody_message_e2ee{type="plain"})[30d] doesn’t seem to work.
flow, 25543 plain messages, vs. 12286 encrypted ones.
flow
Link Mauve, I assume plain only includes message stanzas with <body/>?
Link Mauve
Out of those, 9742 OTR, 1917 OMEMO, 626 legacy OpenPGP, 0 OX.
!XSF_Martinhas left
Link Mauve
flow, messages with <body/> which don’t have one of the encrypted payloads too.
flow
Link Mauve, thanks
flow
Maybe you could make a graphana graph with sum_over_time?
Link Mauve
The source code of this module is here: https://hg.prosody.im/prosody-modules/file/70e5bab388d8/mod_measure_message_e2ee/mod_measure_message_e2ee.lua
Link Mauve
flow, sure!
Link Mauve
That could be more useful than the raw data.
dwd
Wow. I thought OTR might have a slim lead, not that it would have 4.5 times the number.
flow
dwd, maybe it's just two people heavily using OTR ;)
flow
Link Mauve, could you further filter this down by unique bare sender JID?
mathieui
dwd, there are probably bots talking to each other using OTR, to be fair
Link Mauve
flow, I don’t have this information available.
flow
Link Mauve, so one would need to modify the prosody module to count not only the stanzas but also the unique senders per encryption scheme
Zash
that sounds suddenly a lot more complex
flow
not sure if this would violate your privacy policy
mathieui
flow, that would probably suck privacy-wise and the prometheus efficiency would be awful
mathieui
one time series per JID is terrible.
rion
muc-sub is nice. if a server will still show the unavailable participant like he is still in muc but offline and with working private messaging with such a contact, that would be perfect.
flow
mathieui, it's not a time series per JID, but a time series per unique JID/encryption scheme
flow
I think
mathieui
which is worse :p
flow
something like "in the last 1h X unique jids used encryption Y"
flow
I don't see how this is worse to what you already do
flow
(performance wise)
Link Mauve
flow, so Prosody would also have to remember and flush out unique JIDs? :/
Link Mauve
That’s starting to get expensive.
rion
moparisthebest: I would definitely implemented muc-sub if it ever comes to a real xep and wrt to my notes above.
Zash
flow: what it currently does is just keeping simple incrementing counters
!XSF_Martinhas joined
krauqhas left
krauqhas joined
marchas left
Link Mauve
flow, the graph with sum_over_time() is seriously slowing down Prometheus.
Link Mauve
It’s using 100% of the CPU for quite some time. :/
Link Mauve
9s of 100% CPU just for 1h.
Link Mauve
1h for the past seven days.
Link Mauve
mathieui, we’re losing values from before ~eleven days ago, is it a Prometheus configuration issue?
mathieui
we might want to purge the database
mathieui
I haven’t done anything serious prometheus since 2 years ago
marchas joined
Tobiashas left
j.rhas left
j.rhas joined
Tobiashas joined
j.rhas left
j.rhas joined
Shellhas left
Shellhas joined
calvinhas left
sonnyhas left
winfriedhas left
winfriedhas joined
pdurbinhas joined
calvinhas joined
sonnyhas joined
Wojtekhas left
pdurbinhas left
lovetoxhas joined
sonnyhas left
Dele (Mobile)has joined
sonnyhas joined
debaclehas left
sonnyhas left
Nekithas joined
Vaulorhas left
Vaulorhas joined
ajhas joined
ajhas left
ajhas joined
dwd
rion, muc-sub is almost MIX, except that MIX delivers messages as traditional message stanzas, and presence likewise, whereas muc-sub doesn't do that.
adiaholichas left
ajhas left
ajhas joined
dwd
rion, MUC Light is basically a MUC butchered into not being presence-driven. It works, but it's also a dead end.
adiaholichas joined
ajhas left
ajhas joined
sonnyhas joined
Daniel
And minus mix pam
sonnyhas left
sonnyhas joined
adiaholichas left
ajhas left
ajhas joined
waqashas joined
sonnyhas left
ajhas left
lovetoxhas left
lovetoxhas joined
joerghas joined
sonnyhas joined
moparisthebest
did the Xabber guys ever end up actually proposing somehing?
moparisthebest
that at least has running code...
dwd
moparisthebest, Yes, running code is good. Although it does have a tendency to risk entrenching a bad solution, so there's that too.
moparisthebest
yep
dwd
moparisthebest, I mean, if my employer imposes its running code on you, you'd really hate some of the stuff that's been done for expediency.
moparisthebest
oh no I'm well aware of "seems to work, ship it!", unfortunately
dwd
moparisthebest, It's why I try to write specs on what we *should* have done...
Zash
What came first, the spec or the implementation?
mathijshas left
mathijshas joined
pdurbinhas joined
Marandahas left
Marandahas joined
sonnyhas left
pdurbinhas left
sonnyhas joined
joerghas left
j.rhas left
Dele (Mobile)has left
sonnyhas left
Dele (Mobile)has joined
Nekithas left
calvinhas left
sonnyhas joined
mr.fisterhas joined
calvinhas joined
sonnyhas left
sonnyhas joined
mathijshas left
mathijshas joined
calvinhas left
calvinhas joined
mukt2has left
Shellhas left
neshtaxmpphas joined
Dele (Mobile)has left
Dele (Mobile)has joined
dwd
Zash, For almost everything I've done that I'm happy with, spec->implementation->spec.