flowI find the world map comparision especially interesting. Germany appears to have a very high search-interest in Matrix
jonas’probably because we love the movie
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
jonas’unobstrusively pulls out a wrench
pep.There's a Matrix 4 coming
jonas’different director and writer. could be less terrible.
ZashITYM Matrix 2
Ge0rGITYM Synapse 1.8.0
pep.Synapse, Matrix, it's all the same
Dele (Mobile)has joined
ralphmjonas’, what do you mean different writer?
ZashHm, going here didn't give me what I hoped for: https://xmpp.org/rfcs/
MattJI always go there, it's handy
ZashWas looking for RFC 7712 tho
jonas’but the RFCs are rendered terribly :-X
ZashNot that bad IMO
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
> 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
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
Ge0rGWhereas the official rendering is also doing accessibility and readability wrong.
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)
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.
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?
ralphmThis is about subpoena's where the response would need to include an RFC.
ralphmjonas’ simply sending a URL is probably not sufficient.
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.
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.
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.
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.
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?
edhelasI'm currently working at the company behind Linphone and they are developping IM features within their clients :)
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.
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
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.
ZashSo limiting reactions to emoji is meh
pep.┗(•̀へ •́ ╮ )
pep.(people have lots of imagination)
pep.XEP-XXXX: Reactions + bob?
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
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.
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.
pep.Right also that
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.
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
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.
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"
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
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.
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.
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.
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?
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’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
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)
larmadwd, I personally agree to that
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.
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.
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.
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.
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.
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’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.
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)
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 ;)
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
Danielflow, if it were my harddrive i would
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
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
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
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
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!!!
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’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
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.
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
dwdpep., libotr is LGPL...
dwd> (There are still new clients getting OTR support fwiw)
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
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
pep.(multiple devices anyone?)
Steve Killehas left
Steve Killehas joined
rionAre you guys taking about deprecating omemo in favor of otr?
ZashI don't think so
Dele (Mobile)has left
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
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 =)
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?
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.
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 ? :)