XSF Discussion - 2020-01-08

https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F01bb8j,%2Fg%2F11bv302qqv

I find the world map comparision especially interesting. Germany appears to have a very high search-interest in Matrix

probably because we love the movie

what's a little bit sad is that the search interest for xmpp decreased by 50% in the last 5 years

jonas’, if only they made a sequel of that movie

flow, if only

aren't they?

There's a Matrix 4 coming

https://www.imdb.com/title/tt10838180/

different director and writer. could be less terrible.

ITYM Matrix 2

ITYM Synapse 1.8.0

Synapse, Matrix, it's all the same

jonas’, what do you mean different writer?

Hm, going here didn't give me what I hoped for: https://xmpp.org/rfcs/

I always go there, it's handy

Was looking for RFC 7712 tho

but the RFCs are rendered terribly :-X

Not that bad IMO

yeah I know it’s an unpopular opinion of mine, hence the :-X

Could be better

sure, for example: https://tools.ietf.org/html/rfc6120 ✏

This is kinda nice tho: https://www.rfc-editor.org/rfc/rfc8700.html

oh that’s true

font could be slightly larger

reminds me of the XEP renderings

jonas’ [13:17]: > sure, for example: https://tools.ietf.org/html/rfc6120 That's the worst skeuomorph in the history of the Internet

The XSF renderings are plain awesome in comparison

And rfc editor isn't rendering any old RFCs in the nice html, so only the 50 years one?

The mandatory page breaks make my eyes bleed, and I don't even want to try to read that on an e book reader.

Only a few very recent ones

And I'm sure they actually have semantically structured source code, so this is absolutely self inflicted

There was a LOT of argument that ASCII is the only thing everone can handle.

Steve Kille: I'm not opposed to having an ASCII version, not even in 2020. What infuriates me is what they call "html" rendering.

Ge0rG, it’s still better than the kilometers of line length on the XSF rendering

jonas’: you are doing Browser wrong.

no, the XSF rendering is doing typography wrong

Whereas the official rendering is also doing accessibility and readability wrong.

> 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 [..]

should have been done a LONG time ago

Like XEPs! 🙂

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)

[citation needed]

🤷

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.

ralphm: Fun fact: I have mostly working scripts for translating XEP XML to and from Markdown

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.”

A subpoena request for a thing which is public?

This is about subpoena's where the response would need to include an RFC.

jonas’ simply sending a URL is probably not sufficient.

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.

And I'm sure people can come up with a saner mechanism in much less than thirty years, if they actually see a need.

Up until this RFC, the canonical version is been plain-text, in that paginated formatting.

Probably even a mechanims to retro-fit the old ASCII submissions into a new format.

And it is not that people didn't use XML as the actual source format, but this change lifts a lot of restrictions.

RFC8651 has been published last October.

Right, its HTML rendering is based on the XML file, not on the plain text.

Yeah, it's the first one.

But as I said, this has taken thirty years.

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.

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.

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.

ralphm: given sufficient motivation, processes can be changed.

Ge0rG, sure, and there are histerical raisins for this.

And they did, eventually.

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.

We can complain about the speed of it, but I think that's too easy.

And not a very productive attitude.

did some of you already played with http://sylkserver.com/ ?

ralphm: I can't fix _all_ the things.

does it act as a nice XMPP-SIP bridge, at least for IM ?

Ge0rG, I think the bar I set was lower than _all_ :-D

edhelas, SIMPLE is still a thing?

yup

wow

I'm currently working at the company behind Linphone and they are developping IM features within their clients :)

https://www.linphone.org/technical-corner/flexisip

I installed their Android app the other day, it was the only one I could get to work reliably

For SIP, not SIMPLE :)

i'm looking for SIP-XMPP gateways

ralphm: well yes, but I read your statement as an equivalent to "provide patches"

do you mean SIMPLE-XMPP?

ah it's not SIMPLE based actually

my bad

Ge0rG, no my statement is more "we can all do a lot better than making dismissive or facetious comments about the work of others."

edhelas, what it is then?

ralphm: well, that's true

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.

https://upload.ik.nu/upload/TJ3QpLXv5HuZn_mQ/such_reactions.png

Eh

Of course there's an animated parrot in there

party parrot!

This is a message from a few minutes ago in my company Slack. To provide an idea of how reactions can be used in practice.

"badly"? :)

I haven't seen anything that bad in Slack or similar yet.

While I was blurring this screenshot, 5 other reaction emoji were added and a bunch more counts.

Zash: this is why I am posting it :-D

I'm not sure we should start by optimizing for that

This MAM response will only contain non-messages!1!!

I think we might have to.

I'm sure dwd can appreciate the picture.

How do you even fit all that on a phone screen

pep., hold on

It eats like 50% of the usable area?

https://upload.ik.nu/upload/y8ugHA41aaG2UpcK/such_reactions_mobile.png

right

ralphm, is that exceptional or do most messages contain that kind of reactions?

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.

virtually

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.

XEP-xxxx: Kindly ask XMPP users to not send too much Reactions in chats (Informational

heh

or we go full ascii ¯\_(ツ)_/¯

This is not ascii

What I find interesting is that there are very few Unicode reactions there; they're mostly custom images.

(-̀◞८̯◟-́)

╯°□°）╯︵ ┻━┻

So limiting reactions to emoji is meh

┗(•̀へ •́ ╮ )

(people have lots of imagination)

XEP-XXXX: Reactions + bob?

Also I quite like the notion of having sequences like ╯°□°）╯︵ ┻━┻ as reactions.

I'm curious if other solutions allow that. I don't think I've seen it in Mattermost or Slack

And 'wat'

щ(ºДºщ)

("Why?!")

pep., No, I haven't either, but it seems potentially useful.

well it's doable in the current spec. "Just" include that in <reaction/>

Oooh. Polls. Those'd work as fastenings with MAMFC very easily.

dwd, for polls I do want the whole history of who voted what, and if they changed their votes etc. :x

Reactions might be ok for quick polls, but for more serious stuff you probably don't want that

You want the possibility to comment alongside your vote, at least. (that is, your message referencing your action of voting, or sth..)

The moment you want anonymous polls it gets a bit harder, true.

Right also that

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.

To come back to the OMEMO talk (from council@): Note that I'm not opposing getting rid of OMEMO.

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.

Just that we don't have anything to replace it.

And I hate the message that this is sending

"We don't care about e2ee"

context for the above: https://logs.xmpp.org/council/2020-01-08#2020-01-08-40325e18d4aac62b

pep., though Daniel proposed to write a blogpost which explains the rationale and why this is a good thing actually.

Is it a good thing

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.

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

pep., yes, it is a good thing for implementation freedom

And what in the meantime? "yeah well you can use that deprecated-or-rejected XEP, because everybody else use it"

"yay standards"

pep., this is nothing new

To me the XSF is shooting itself in the foot

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.

or even push SEX forward, with a slightly less awful name

These are not OMEMO replacements

People have used non-SASL authentication for ages after we obsoleted it.

they're perfectly valid encryption mechanisms for sure, but they don't do PFS (not that I'm arguing in favor of PFS)

pep., I’d also argue that OMEMO is not a good solution

and the replacements I mentioned are all better than OMEMO for the general userbase

jonas’, that's another debate

I also agree

so this is another reason why this is a good thing™

OMEMO is popular. Popularity does not equal quality.

it encourages the deployment of (for some metric) better alternatives

I also agree getting rid of PFS for the masses is a good thing. But that's not the debate at hand

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.

ralphm, the current best thing we have is OMEMO. It's not good, but it's the best we have

larma, yes, and it doesn't meet our objectives, so that's terrible.

Which objective?

larma: #4 of XEP-0001

larma, https://xmpp.org/extensions/xep-0001.html#objectives number 4

"good is the enemy of perfect"?

It doesn't strictly violate it either

it just lacks documentation

larma, I think it does

even if it is strictly legal, the ambiguity of the situation is encumberence enough

pep., Not good is the enemy of good, too.

what ambiguity?

larma, whether it is a legal thing to do without using the GPL

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.

where "it" is "implementing and using the Signal protocol"

dwd, what's the actual reason behind this move?

pep., I've explained that several times.

well "Signal" is probably a trademark and thus can't be used in the XEP, I agree

but that's again a documentation issue

larma, I’m talking about the protocol, not the name

pep., Unless by "actual" you're trying to imply I'm not really saying.

the cryptographic protocol is pretty well specified in their public domain documents

That it can't be implemented in proprietary products etc.(?)

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.

I think there even was a library that changed licenses for this.

pep., that it can’t be implemented *in non-GPL products

pep., and yes, the XSF expressly supports implementations open or closed alike.

jonas’, sure. I doubt this is really in issue in practice though.

pep., that’s not the point.

it violates objective 4

well if you create a derivative work of libsignal it has to be under GPL, but I doubt that you have to do so

pep., Why do you think that's not an issue?

whether it’s a prolbem in practice because everyone who does OMEMO also happens to be okay with the GPL is a different issue

Companies and proprietary implementations of our open protocols are not a bad thing, and explicitly part of the XSF's DNA.

That I can see indeed

pep., I don't understand why you want to argue against this.

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?

flow, URL?

I guess the log in the PR would explain the reasons

I don't especially agree, but that debate is different from the points I'm bringing forward with OMEMO

ralphm, ^

jonas’, no it doesn't, editor closed it

pep., Put it this way - if OMEMO genuinely cannot be implemented without a GPL library, should we kill it?

flow, URL please then?

that was probably me, and I might know more

(when I see the PR)

jonas’, https://github.com/xsf/xeps/pull/460

dwd, I personally agree to that

dwd, that's not my point in this debate. I'm not answering this question

pep., but that’s the *reason* for this debate

pep., except it isn't. Because if the argument is not clearly worded, it might taken as a Board stance.

flow, ah, the reason is right there: inactivity.

I didn’t get a reply from the author in weeks

jonas’, of course the question is "why went the author silent"

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)

flow, that I cannot anwser

We are sending a message that I don't want to send

and there is a larger backstory to that behind what you can read from the comments in the PR

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.

pep., One problem here is that it forces other projects to send the same message.

Which projects?

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)

pep., Look at, for example, the OMEMO ticket against Swift.

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).

So you need to kill it as long as we don't have a replacement. Like it's become a mission right now?

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

Swift can very well implement OX

Gajim also supports OX. Swift can also drive the adoption around OX

I'm sure others would implement it

pep., the problem (the XEP violates a criterium for XEPs) was spotted, the problem is known, and it needs to be fixed now.

(I would)

the combination of not being able to solve backward compat and good enough lessens the incentives to work on 'omemo 2'

if we want to further represent our objectives

Daniel, why isn't omemo2 backwards compatible? Couldn't clients just use the same key material and crypto primitives with OMEMO1 and OMEMO2?

it sohuld never have come this far, but here we are

flow, it won’t be compatible on the wire by definition, that’s incompatibility enough

it's probably not backward compat in a non-gpl way

jonas’, not in my book

pep., Are you arguing, then, that since OMEMO has a viable replacement it's OK to get rid of it?

flow, in practice it is

OMEMO1 clients won’t be able to read OMEMO2 messages

dwd, when, not since

hardcoded strings and unspeced protobuf

jonas’, sure the XML element definition will be different, but the keys could be the same

it’s "This message is OMEMO encrypted ..." all over again

that may or may not be gpl

pep., Because you cannot argue that Swift can just implement OX unless you believe that OX is a replacement.

plus if we are going to introdcue breaking changes we also might want to fix other things

something second system syndrome

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)

jonas’> OMEMO1 clients won’t be able to read OMEMO2 messages sure but there is nothing one can do about it

flow, and that’s why people don’t want to move from OMEMO1

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.

jonas’, well yes and no. there are some relatively low hanging fruit that could be fixed

but not backwards compatible

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

ralphm, i think nobody is denying that it is a shitty xep

Daniel, cp xep-0384.xml inbox/daniels-omemo2.xml and get started? ;)

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

jonas’, not _my_ harddrive 🙂

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.

flow, IMO, OMEMO can die in a housefire, but that’s just me. I think we’re quite alone on that island ;)

jonas’ not at all

jonas’, It's fine if you don't care about a XEP if you don't actively fight it

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

flow, I don’t "fight" it for those reasons.

flow, I fight it because I think that ralphm and dwd are right.

my fight against OMEMO itself mostly consists of "No omemo here" replies to messages which are OMEMO encrypted *shrug*

ok, let me specifiy this "if you don't actively fight it's development"

pep., yes, the choice of GPL is intentional, and detrimental to open protocol development.

(because there is no protocol spec)

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.

flow, thus supporting your YMMV

ralphm, is it against the XSF objective 4 if implementing a protocol using a GPL library is cheaper than implementing it without?

larma, no, but the question here is whether it is legally POSSIBLE to implement it without the GPL library.

that ^

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

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*

jonas’, you could argue the same for *every* XEP

larma, no

XEPs which fully describe the protocol can clearly be implemented non-GPL

because they are under XSF IPR

XEPs which rely solely on other open standards (e.g. RFCs)are the same

jonas’, sure, so if I just put all the required stuff in the XEP what happens then?

larma, then you’re liable

if that’s under GPL and you passed it to the XSF while having the IPR signed

you will be liable for that when moxie sues an implementation

the implementation can point at the XEP, the XSF can point at you

jonas’, Actually I suspect the XSF might be liable.

Isn't that how cleanroom implementations are done? One team looks at gpl code and writes docs.

dwd, at this point, probably yes, because we already have publicly stated that we have doubts

"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

dwd: that's an interesting point that might graduate it to Board territory.

Daniel, ^

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

So I guess we can point to Daniel.

larma, nobody who hasn’t implemented it without libsignal does.

(who put in the dependency on libsignal, if I remember correctly)

larma, please do so

flow, one of the reasons why the SIG is happening I think

larma, i.e., to find out, try that

flow, I also want that, transparency

I think it is easy to find out what is missing. Just add everything that is missing from the XEP

pep., that nice, but you don't have to form a SIG to invite people to collaborate ;)

flow this

Well.. people are what they are

If OMEMO2 is only using a different wire protocol (replacing protobuf with xml) than that should be easy, because the wire protocol is protobuf

You need to get them motivated to do things

We're not all paid to do stuff

a SIG is not super special. I would also like to point to XEP-0019 for a bit of history of SIGs.

I've read that one yes

flow, if it were my harddrive i would

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.

pep., You know, I'm not sure any of us are paid to do this anymore.

however it doesn’t really solve the "we don’t know how to migrate" issue

Daniel, Well, non-migration between crypto protocols isn't unique to OMEMO.

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.

Daniel, it appears there is no good solution besides probably a grace period where clients send OMEMO1 and OMEMO2 together

don't ask me how long that period should be

Daniel, And is a particular problem with E2EE in IM. Long talks about that in the MLS WG as well.

OTOH it appears that most OMEMO developers are agile

flow, at this point I'd start working on MLS rather than having a migration period of "forever" already between OMEMO1 and OMEMO2

pep., great!

(not me personally)

pep., do ash you like, but I think it is sensible to put effort into OMEMO2

And another migration period of "forever" between OMEMO2 and MLS

pep., (aw)

ralphm, as funny as it might seem from me arguing about all this, I don't use e2ee very much myself :)

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.

I think the migration effort outweights everything

Debian, RHEL, $things

In 10 years we're still sending OMEMO1

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.

ralphm, I’m curious which aspect you’re talking about, because my experience with OTR was quite pleasant, while OMEMO was terrible.

s/was/was and still is/g ✏

jonas’, I'm also curious which aspect of OTR you find pleasant

(compared to OMEMO)

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

Jr fubhyq nyy hfr EBG13

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., it isn’t instrusive like OMEMO is.

jonas’, Also you can type OTR manually.

dwd, https://ppjet.bouah.net/rot13.py (poezio plugin)

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.

Ah wait I have a better one now that we have the E2EE API :p

jonas’, I remember mod_otr in prosody preventing you from sending messages that were not OTR encrypted.

I don't think that's really better

pep., that’s a problem of a server deployment

not a general problem of the thing

But you got to get the green checks

:)

pep., missing the point

jonas’: green checkmarks!!!1!1!eleven

I don't think OMEMO is worse in this regard tbh

MUST HAVE GREEN CHECKMARKS AND E2EE!!!!

That's a policy of the clients. Enabling OTR/OMEMO by default

Whether you are capable of receiving it or not

MUST HAVE GREEN CHECKMARKS AND E2EE ENABLED BY DEFAULT!!!

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.

pep., no, the difference is the mechanism of discovery of support

the one used by OMEMO is unreliable

("are keys published?")

the one used by OTR is reliable, barring server intervention ("is the secret whitespace handshake sent in the message I just got?") ✏

Ok, on the theory maybe

ralphm, agreed

pep., in practice.

In practice clients would probably just enable OTR because what Zash said

also, you notice when the OTR handshake fails and don’t blindly send encrypted messages which won’t be readable

because OTR has a handshake

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.

Ok

(or what they did before they dropped support for OTR in favour of OMEMO)

jonas’: A Chatsecure always sent me otr garbage although I had never otr enabled with any client on that jid …

(There are still new clients getting OTR support fwiw)

!XSF_Martin, neat, that’s the first time I hear that. However, that garbage was most certainly not a message you missed.

in contrast to OMEMO

pep., libotr is LGPL...

dwd, context?

> (There are still new clients getting OTR support fwiw)

I was thinking about a fork of conversations. That also removed OMEMO support iirc

But I'm sorry I don't understand what you want to say

pep.: Not all those forks that just did search and replace on everything, including the OMEMO siacs namespace?

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.

Ah my bad it's not a fork of conversations. I was thinking of https://github.com/coyim/coyim

?OTRv23?

Anyone?

:-)

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

?OTRvTemp?

(multiple devices anyone?)

Are you guys taking about deprecating omemo in favor of otr?

I don't think so

rion, No.

I think deprecating omemo in favor of $some_future_protocol_that_might_be_better ?

rion, For two reasons: Firstly, we don't deprecate "in favour of" anything. Secondly, we all agree that OTR is a bit pants.

rion, That said, there *is* an OTR XEP, and everyone is, I think, confident it can be implemented by anyone.

when you say "implemented by everyone" are you speaking technically or legally ?

rion, indeed we're not deprecating in favor of anything..

because surely omemo and otr are both capable of being implemented by anyone from a technical perspective right?

I said "implemented by anyone", meaning that anyone *could* implement. There is both technical information available and no licensing restrictions upon it.

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

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

in Russia any encryption unavailable for deciphering by the government is illegal. But anyway I hope nothing was implemented in vain :)

moparisthebest, Are you saying the XSF should take the position that all IPR is meaningless?

there are probably other reasons to do OMEMO differently, I just don't think licensing of any code should be one of them

moparisthebest, And you are very much in the minority there.

I think those XEPs should have something about availability for government :)

sure, otherwise it's illegal in russia and probably china, better remove TLS too since not everyone can implement it

/sarcasm (just to be clear :) )

we just need some xeps how to properly implement backdoors on servers

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?

moparisthebest, No, I don't think so.

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"

moparisthebest, Oh, deprecation you mean.

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"

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"

it's almost a theme isn't it?

moparisthebest, I've implemented MIX twice. That whole situation frustrates the hell out of me, too.

moparisthebest, But XHTML-IM... Yeah, I'm not sorry to see that one go.

it seems like XSF is working/waiting on the *perfect* solution, while everyone else trudges along with *good enough*

moparisthebest, Also I think I'm probably right if I asserted that OTR is the most widely deployed outside this bubble.

xhtml-im was good. maybe not that good as markdown but good anyway.

rion, as has been pointed out countless times, we don't have anything resembling a markdown XEP :)

rion, Yes, except literally every client that implemented it had a security issue relating to it.

(also markdown doesn't support coloring)

markdown is a html superset, therefore it also sucks

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.

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

dwd: well I filtered it in iris. everything but css styles which made a lot of fun to filter out =)

moparisthebest: everything is terrible

rion, "fun" is not what I want in security-sensitive code. :-)

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 :)

So, who wants to cp xep-0071.xml inbox/xhtmlim-but-better.xml ? Link Mauve?

I understand that but when on 1st april you inject a style which put a group chat up side down it looks awesome :)

for everyone ))

moparisthebest, I've argued before that I'm concerned we may have gone in a bad direction with MIX.

Zash, sure.

moparisthebest, I joke that I've lost two jobs due to MIX, and I'm not entirely exaggerating either.

inbox/xhtmlim-this-time-serous.xml works better ;-)

We did that joke, I think.

any better time to try and fix it than now maybe dwd ? :)

rion, https://xmpp.org/extensions/xep-0402.html

XHTML-IM 2: Electric Boogaloo

moparisthebest, Yeah, lots of good times, like when I'm not swamped by both work and taking on too much from fastenings.

dwd, you lost jobs due to MIX?

flow, As I say, it's something of an exaggeration.

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.

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.

flow, But had MIX been widely deployed in, erm, March last year, I'd probably still have the job I had then.

I see. And I assume the resources (people, money, bitcoin, …) to implement MIX where not available?

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

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?

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?

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

flow, I do have stats of that at https://stats.jabberfr.org/

Hmm, how do you do queries to Prometheus again?

flow, seems like out of all of the encryption methods, OTR is by far the most popular.

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/

I think Xabber has their own, can't recall if it was submitted or not

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

> Occupants cannot hide behind nicks. Their real bare JID is always visible to everyone I like this (no sarcasm)

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

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

and if you just look at who else has custom shit to fix the push issue tigase is also on the list

> No exchange of any <presence/> stanza inside the room. online/offline status still has to be somehow reflected

Hmm, Error executing query: parse error at char 40: range specification must be preceded by a metric selector, but follows a *promql.AggregateExpr instead

sum(prosody_message_e2ee{type="plain"})[30d] doesn’t seem to work.

sum_over_time(prosody_message_e2ee{type="plain"}[30d]) ?

Nor does taking the sum out.

flow, 25543 plain messages, vs. 12286 encrypted ones.

Link Mauve, I assume plain only includes message stanzas with <body/>?

Out of those, 9742 OTR, 1917 OMEMO, 626 legacy OpenPGP, 0 OX.

flow, messages with <body/> which don’t have one of the encrypted payloads too.

Link Mauve, thanks

Maybe you could make a graphana graph with sum_over_time?

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

flow, sure!

That could be more useful than the raw data.

Wow. I thought OTR might have a slim lead, not that it would have 4.5 times the number.

dwd, maybe it's just two people heavily using OTR ;)

Link Mauve, could you further filter this down by unique bare sender JID?

dwd, there are probably bots talking to each other using OTR, to be fair

flow, I don’t have this information available.

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

that sounds suddenly a lot more complex

not sure if this would violate your privacy policy

flow, that would probably suck privacy-wise and the prometheus efficiency would be awful

one time series per JID is terrible.

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.

mathieui, it's not a time series per JID, but a time series per unique JID/encryption scheme

I think

which is worse :p

something like "in the last 1h X unique jids used encryption Y"

I don't see how this is worse to what you already do

(performance wise)

flow, so Prosody would also have to remember and flush out unique JIDs? :/

That’s starting to get expensive.

moparisthebest: I would definitely implemented muc-sub if it ever comes to a real xep and wrt to my notes above.

flow: what it currently does is just keeping simple incrementing counters

flow, the graph with sum_over_time() is seriously slowing down Prometheus.

It’s using 100% of the CPU for quite some time. :/

9s of 100% CPU just for 1h.

1h for the past seven days.

mathieui, we’re losing values from before ~eleven days ago, is it a Prometheus configuration issue?

we might want to purge the database

I haven’t done anything serious prometheus since 2 years ago

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.

rion, MUC Light is basically a MUC butchered into not being presence-driven. It works, but it's also a dead end.

And minus mix pam

did the Xabber guys ever end up actually proposing somehing?

that at least has running code...

moparisthebest, Yes, running code is good. Although it does have a tendency to risk entrenching a bad solution, so there's that too.

yep

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.

oh no I'm well aware of "seems to work, ship it!", unfortunately

moparisthebest, It's why I try to write specs on what we *should* have done...

What came first, the spec or the implementation?

Zash, For almost everything I've done that I'm happy with, spec->implementation->spec.