flowI 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
flowwhat's a little bit sad is that the search interest for xmpp decreased by 50% in the last 5 years
flowjonas’, if only they made a sequel of that movie
jonas’flow, if only
Ge0rGaren'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.
ZashITYM Matrix 2
mukt2has joined
krauqhas joined
Ge0rGITYM 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
ralphmjonas’, 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
ZashHm, going here didn't give me what I hoped for: https://xmpp.org/rfcs/
Maxhas left
Maxhas joined
marchas left
marchas joined
larmahas left
MattJI always go there, it's handy
larmahas joined
ZashWas looking for RFC 7712 tho
jonas’but the RFCs are rendered terribly :-X
sonnyhas left
betahas left
ZashNot that bad IMO
Alexhas left
jonas’yeah I know it’s an unpopular opinion of mine, hence the :-X
ZashCould be better
jonas’sure, for example the official IETF html rendering
jonas’sure, for example: https://tools.ietf.org/html/rfc6120
ZashThis 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
Ge0rGjonas’ [13:17]:
> sure, for example: https://tools.ietf.org/html/rfc6120
That's the worst skeuomorph in the history of the Internet
Ge0rGThe XSF renderings are plain awesome in comparison
eevvoorhas joined
Shellhas joined
Ge0rGAnd rfc editor isn't rendering any old RFCs in the nice html, so only the 50 years one?
Ge0rGThe mandatory page breaks make my eyes bleed, and I don't even want to try to read that on an e book reader.
ZashOnly a few very recent ones
Ge0rGAnd I'm sure they actually have semantically structured source code, so this is absolutely self inflicted
Steve KilleThere was a LOT of argument that ASCII is the only thing everone can handle.
Ge0rGSteve 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
Ge0rGjonas’: you are doing Browser wrong.
jonas’no, the XSF rendering is doing typography wrong
betahas left
Ge0rGWhereas 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 Killeshould have been done a LONG time ago
ZashLike XEPs! 🙂
Ge0rGit 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
ralphmCome 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
Zashralphm: Fun fact: I have mostly working scripts for translating XEP XML to and from Markdown
ralphmE.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
ralphmThis is about subpoena's where the response would need to include an RFC.
ralphmjonas’ simply sending a URL is probably not sufficient.
Shellhas left
Shellhas joined
stpeterhas left
Ge0rGralphm: 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
Ge0rGAnd I'm sure people can come up with a saner mechanism in much less than thirty years, if they actually see a need.
ralphmUp until this RFC, the canonical version is been plain-text, in that paginated formatting.
Ge0rGProbably even a mechanims to retro-fit the old ASCII submissions into a new format.
ralphmAnd it is not that people didn't use XML as the actual source format, but this change lifts a lot of restrictions.
Ge0rGRFC8651 has been published last October.
goffihas left
ralphmRight, its HTML rendering is based on the XML file, not on the plain text.
Ge0rGYeah, it's the first one.
Ge0rGBut as I said, this has taken thirty years.
Ge0rGThe 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
ralphmIt 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.
Ge0rGOTOH, I can't read most RFCs on my smartphone screen because the fixed-width fixed-page-width mandatory-line-breaks format is just bonkers.
Ge0rGralphm: given sufficient motivation, processes can be changed.
ralphmGe0rG, sure, and there are histerical raisins for this.
ralphmAnd they did, eventually.
Ge0rGralphm: 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.
ralphmWe can complain about the speed of it, but I think that's too easy.
ralphmAnd not a very productive attitude.
debaclehas joined
edhelasdid some of you already played with http://sylkserver.com/ ?
Ge0rGralphm: I can't fix _all_ the things.
edhelasdoes it act as a nice XMPP-SIP bridge, at least for IM ?
ralphmGe0rG, I think the bar I set was lower than _all_ :-D
ralphmedhelas, SIMPLE is still a thing?
edhelasyup
ralphmwow
Shellhas left
edhelasI'm currently working at the company behind Linphone and they are developping IM features within their clients :)
MattJI installed their Android app the other day, it was the only one I could get to work reliably
lorddavidiiihas joined
MattJFor SIP, not SIMPLE :)
edhelasi'm looking for SIP-XMPP gateways
Ge0rGralphm: well yes, but I read your statement as an equivalent to "provide patches"
Steve Killedo you mean SIMPLE-XMPP?
edhelasah it's not SIMPLE based actually
edhelasmy bad
emushas left
lorddavidiiihas left
lorddavidiiihas joined
UṣLhas left
Shellhas joined
krauqhas left
ralphmGe0rG, no my statement is more "we can all do a lot better than making dismissive or facetious comments about the work of others."
ralphmedhelas, what it is then?
Ge0rGralphm: well, that's true
lorddavidiiihas left
lorddavidiiihas joined
Shellhas left
Lancehas joined
lorddavidiiihas left
pdurbinhas joined
Nekithas joined
lorddavidiiihas joined
ralphmBy 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.
Link Mauveralphm, is that exceptional or do most messages contain that kind of reactions?
ralphmNo 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.
ralphmvirtually
sonnyhas left
ralphmI 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.
edhelasXEP-xxxx: Kindly ask XMPP users to not send too much Reactions in chats (Informational
ralphmheh
edhelasor we go full ascii ¯\_(ツ)_/¯
pep.This is not ascii
dwdWhat I find interesting is that there are very few Unicode reactions there; they're mostly custom images.
pep.(-̀◞८̯◟-́)
edhelas╯°□°）╯︵ ┻━┻
ZashSo limiting reactions to emoji is meh
pep.┗(•̀へ •́ ╮ )
pep.(people have lots of imagination)
pep.XEP-XXXX: Reactions + bob?
Wojtekhas left
dwdAlso 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
ZashAnd 'wat'
pep.щ(ºДºщ)
pep.("Why?!")
sonnyhas joined
Wojtekhas joined
mukt2has left
dwdpep., No, I haven't either, but it seems potentially useful.
pep.well it's doable in the current spec. "Just" include that in <reaction/>
dwdOooh. 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..)
dwdThe 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
ralphmYeah, 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.
ralphmlarma: 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
ralphmpep. 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"
ralphmpep., 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
ralphmPeople 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™
ZashOMEMO 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
ralphmpep. 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.
larmaralphm, the current best thing we have is OMEMO. It's not good, but it's the best we have
ralphmlarma, yes, and it doesn't meet our objectives, so that's terrible.
larmaWhich objective?
ralphmlarma: #4 of XEP-0001
jonas’larma, https://xmpp.org/extensions/xep-0001.html#objectives number 4
pep."good is the enemy of perfect"?
larmaIt doesn't strictly violate it either
larmait just lacks documentation
jonas’larma, I think it does
jonas’even if it is strictly legal, the ambiguity of the situation is encumberence enough
dwdpep., Not good is the enemy of good, too.
larmawhat ambiguity?
jonas’larma, whether it is a legal thing to do without using the GPL
ralphmlarma: 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
dwdpep., I've explained that several times.
larmawell "Signal" is probably a trademark and thus can't be used in the XEP, I agree
larmabut that's again a documentation issue
jonas’larma, I’m talking about the protocol, not the name
dwdpep., Unless by "actual" you're trying to imply I'm not really saying.
larmathe cryptographic protocol is pretty well specified in their public domain documents
pep.That it can't be implemented in proprietary products etc.(?)
ralphmlarma, 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.
ralphmI think there even was a library that changed licenses for this.
jonas’pep., that it can’t be implemented *in non-GPL products
ralphmpep., 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
larmawell if you create a derivative work of libsignal it has to be under GPL, but I doubt that you have to do so
dwdpep., 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
ralphmCompanies 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
ralphmpep., I don't understand why you want to argue against this.
flowI 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, ^
flowjonas’, no it doesn't, editor closed it
dwdpep., 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)
flowjonas’, https://github.com/xsf/xeps/pull/460
larmadwd, 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
ralphmpep., 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
flowjonas’, 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
flowand there is a larger backstory to that behind what you can read from the comments in the PR
ralphmpep., and I want to clearly communicate to everyone in our community that we definitely consider companies and proprietary implementations as part of our community.
dwdpep., One problem here is that it forces other projects to send the same message.
pep.Which projects?
Danielflow, 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)
dwdpep., Look at, for example, the OMEMO ticket against Swift.
dwdpep., 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?
Danielso 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)
Danielthe 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
flowDaniel, 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
Danielit's probably not backward compat in a non-gpl way
flowjonas’, not in my book
dwdpep., 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
Danielhardcoded strings and unspeced protobuf
flowjonas’, 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
Danielthat may or may not be gpl
dwdpep., Because you cannot argue that Swift can just implement OX unless you believe that OX is a replacement.
Danielplus 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)
flowjonas’> 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
larmaJust 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.
Danieljonas’, well yes and no. there are some relatively low hanging fruit that could be fixed
Danielbut not backwards compatible
ralphmA 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
Danielralphm, i think nobody is denying that it is a shitty xep
jonas’Daniel, cp xep-0384.xml inbox/daniels-omemo2.xml and get started? ;)
flowjonas’> 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
Danieljonas’, not _my_ harddrive 🙂
ralphmlarma: 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 ;)
ralphmjonas’ not at all
flowjonas’, 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*
flowok, let me specifiy this "if you don't actively fight it's development"
ralphmpep., 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
larmaralphm, 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.
flowthat ^
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
ralphmlarma, 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*
larmajonas’, 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
larmajonas’, 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
dwdjonas’, Actually I suspect the XSF might be liable.
ZashIsn'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
ralphmdwd: that's an interesting point that might graduate it to Board territory.
flowDaniel, ^
larmaAs 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
ralphmSo 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
flowlarma, 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
flowI think it is easy to find out what is missing. Just add everything that is missing from the XEP
flowpep., that nice, but you don't have to form a SIG to invite people to collaborate ;)
ralphmflow this
pep.Well.. people are what they are
larmaIf 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
ralphma 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
Danielflow, if it were my harddrive i would
Shellhas left
ralphmpep., 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.
dwdpep., You know, I'm not sure any of us are paid to do this anymore.
Danielhowever it doesn’t really solve the "we don’t know how to migrate" issue
dwdDaniel, Well, non-migration between crypto protocols isn't unique to OMEMO.
ralphmThey'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.
flowDaniel, it appears there is no good solution besides probably a grace period where clients send OMEMO1 and OMEMO2 together
flowdon't ask me how long that period should be
sonnyhas left
dwdDaniel, And is a particular problem with E2EE in IM. Long talks about that in the MLS WG as well.
flowOTOH 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
ralphmpep., great!
pep.(not me personally)
flowpep., 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
ralphmpep., (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 :)
ralphmI 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
ralphmpep., 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’s/was/was and still is/
jonas’s/was/was and still is/g
pep.jonas’, I'm also curious which aspect of OTR you find pleasant
pep.(compared to OMEMO)
Danieland 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
ralphmjonas’, 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.
jonas’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
Zashjonas’: green checkmarks!!!1!1!eleven
pep.I don't think OMEMO is worse in this regard tbh
ZashMUST 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
ZashMUST HAVE GREEN CHECKMARKS AND E2EE ENABLED BY DEFAULT!!!
debaclehas joined
pdurbinhas left
ralphmAdditionally, 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_Martinjonas’: 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
dwdpep., 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
Zashpep.: Not all those forks that just did search and replace on everything, including the OMEMO siacs namespace?
dwdpep., 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?
dwdAnyone?
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
rionAre you guys taking about deprecating omemo in favor of otr?
ZashI don't think so
mukt2has left
Dele (Mobile)has left
mathijshas left
mathijshas joined
dwdrion, No.
moparisthebestI think deprecating omemo in favor of $some_future_protocol_that_might_be_better ?
dwdrion, For two reasons: Firstly, we don't deprecate "in favour of" anything. Secondly, we all agree that OTR is a bit pants.
dwdrion, That said, there *is* an OTR XEP, and everyone is, I think, confident it can be implemented by anyone.
moparisthebestwhen you say "implemented by everyone" are you speaking technically or legally ?
pep.rion, indeed we're not deprecating in favor of anything..
moparisthebestbecause surely omemo and otr are both capable of being implemented by anyone from a technical perspective right?
dwdI said "implemented by anyone", meaning that anyone *could* implement. There is both technical information available and no licensing restrictions upon it.
moparisthebestlegally, 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
moparisthebestso 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
rionin Russia any encryption unavailable for deciphering by the government is illegal. But anyway I hope nothing was implemented in vain :)
dwdmoparisthebest, Are you saying the XSF should take the position that all IPR is meaningless?
moparisthebestthere are probably other reasons to do OMEMO differently, I just don't think licensing of any code should be one of them
dwdmoparisthebest, And you are very much in the minority there.
rionI think those XEPs should have something about availability for government :)
moparisthebestsure, 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 :) )
rionwe just need some xeps how to properly implement backdoors on servers
moparisthebestI 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?
dwdmoparisthebest, No, I don't think so.
moparisthebestQ: "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"
dwdmoparisthebest, Oh, deprecation you mean.
moparisthebestQ: "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"
moparisthebestQ: "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"
moparisthebestit's almost a theme isn't it?
dwdmoparisthebest, I've implemented MIX twice. That whole situation frustrates the hell out of me, too.
dwdmoparisthebest, But XHTML-IM... Yeah, I'm not sorry to see that one go.
moparisthebestit seems like XSF is working/waiting on the *perfect* solution, while everyone else trudges along with *good enough*
dwdmoparisthebest, Also I think I'm probably right if I asserted that OTR is the most widely deployed outside this bubble.
rionxhtml-im was good. maybe not that good as markdown but good anyway.
moparisthebestrion, as has been pointed out countless times, we don't have anything resembling a markdown XEP :)
dwdrion, Yes, except literally every client that implemented it had a security issue relating to it.
moparisthebest(also markdown doesn't support coloring)
Zashmarkdown is a html superset, therefore it also sucks
dwdmoparisthebest, 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.
moparisthebestalso 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
riondwd: well I filtered it in iris. everything but css styles which made a lot of fun to filter out =)
calvinhas joined
Zashmoparisthebest: everything is terrible
dwdrion, "fun" is not what I want in security-sensitive code. :-)
moparisthebestI 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 :)
ZashSo, who wants to cp xep-0071.xml inbox/xhtmlim-but-better.xml ? Link Mauve?
winfriedhas left
winfriedhas joined
rionI understand that but when on 1st april you inject a style which put a group chat up side down it looks awesome :)
rionfor everyone ))
dwdmoparisthebest, I've argued before that I'm concerned we may have gone in a bad direction with MIX.
winfriedhas left
winfriedhas joined
Link MauveZash, sure.
dwdmoparisthebest, I joke that I've lost two jobs due to MIX, and I'm not entirely exaggerating either.
rioninbox/xhtmlim-this-time-serous.xml works better ;-)
dwdWe did that joke, I think.
moparisthebestany better time to try and fix it than now maybe dwd ? :)
dwdmoparisthebest, Yeah, lots of good times, like when I'm not swamped by both work and taking on too much from fastenings.
flowdwd, you lost jobs due to MIX?
dwdflow, As I say, it's something of an exaggeration.
dwdflow, 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
dwdflow, 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
dwdflow, But had MIX been widely deployed in, erm, March last year, I'd probably still have the job I had then.
j.rhas left
flowI see. And I assume the resources (people, money, bitcoin, …) to implement MIX where not available?
j.rhas joined
mukt2has left
moparisthebestmaybe 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
rionwhat if MIX didn't exist and had to be designed again. would it go as an extension to MUC instead of completely separate protocol?
flowLink 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?
flowhttps://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 Mauveflow, I do have stats of that at https://stats.jabberfr.org/
krauqhas left
Link MauveHmm, how do you do queries to Prometheus again?
Link Mauveflow, seems like out of all of the encryption methods, OTR is by far the most popular.
moparisthebestrion, 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/
moparisthebestI think Xabber has their own, can't recall if it was submitted or not
mathijshas left
mathijshas joined
moparisthebestI 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)
moparisthebesthave 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
Danielmuc/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
Danieland 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 MauveHmm, Error executing query: parse error at char 40: range specification must be preceded by a metric selector, but follows a *promql.AggregateExpr instead
Link Mauvesum(prosody_message_e2ee{type="plain"})[30d] doesn’t seem to work.
Link Mauveflow, 25543 plain messages, vs. 12286 encrypted ones.
flowLink Mauve, I assume plain only includes message stanzas with <body/>?
Link MauveOut of those, 9742 OTR, 1917 OMEMO, 626 legacy OpenPGP, 0 OX.
!XSF_Martinhas left
Link Mauveflow, messages with <body/> which don’t have one of the encrypted payloads too.
flowLink Mauve, thanks
flowMaybe you could make a graphana graph with sum_over_time?
Link MauveThe 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 Mauveflow, sure!
Link MauveThat could be more useful than the raw data.
dwdWow. I thought OTR might have a slim lead, not that it would have 4.5 times the number.
flowdwd, maybe it's just two people heavily using OTR ;)
flowLink Mauve, could you further filter this down by unique bare sender JID?
mathieuidwd, there are probably bots talking to each other using OTR, to be fair
Link Mauveflow, I don’t have this information available.
flowLink Mauve, so one would need to modify the prosody module to count not only the stanzas but also the unique senders per encryption scheme
Zashthat sounds suddenly a lot more complex
flownot sure if this would violate your privacy policy
mathieuiflow, that would probably suck privacy-wise and the prometheus efficiency would be awful
mathieuione time series per JID is terrible.
rionmuc-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.
flowmathieui, it's not a time series per JID, but a time series per unique JID/encryption scheme
flowI think
mathieuiwhich is worse :p
flowsomething like "in the last 1h X unique jids used encryption Y"
flowI don't see how this is worse to what you already do
flow(performance wise)
Link Mauveflow, so Prosody would also have to remember and flush out unique JIDs? :/
Link MauveThat’s starting to get expensive.
rionmoparisthebest: I would definitely implemented muc-sub if it ever comes to a real xep and wrt to my notes above.
Zashflow: what it currently does is just keeping simple incrementing counters
!XSF_Martinhas joined
krauqhas left
krauqhas joined
marchas left
Link Mauveflow, the graph with sum_over_time() is seriously slowing down Prometheus.
Link MauveIt’s using 100% of the CPU for quite some time. :/
Link Mauve9s of 100% CPU just for 1h.
Link Mauve1h for the past seven days.
Link Mauvemathieui, we’re losing values from before ~eleven days ago, is it a Prometheus configuration issue?
mathieuiwe might want to purge the database
mathieuiI 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
dwdrion, 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
dwdrion, 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
DanielAnd 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
moparisthebestdid the Xabber guys ever end up actually proposing somehing?
moparisthebestthat at least has running code...
dwdmoparisthebest, Yes, running code is good. Although it does have a tendency to risk entrenching a bad solution, so there's that too.
moparisthebestyep
dwdmoparisthebest, 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.
moparisthebestoh no I'm well aware of "seems to work, ship it!", unfortunately
dwdmoparisthebest, It's why I try to write specs on what we *should* have done...
ZashWhat 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
dwdZash, For almost everything I've done that I'm happy with, spec->implementation->spec.
XSF Discussion - 2020-01-08