XSF Discussion - 2019-02-09

Good morning

I'm going to upgrade xmpp:xmpp.org, which means this room will be (hopefully briefly) unavailable, and you will need to rejoin

Hopefully for the last time, because the next version preserves room occupants between restarts :)

Wait. Or am I?

Looks like an OS upgrade will be needed first

Do we get MAM here then?

or at least a history that doesnt save chatstates

MAM is the goal, yes

great 😎

lovetox, are you confusing this room with jdev@?

maybe, does this one not save chatstates :D

I don’t think it does

but I haven’t been using a non-always-on client in MUCs for a while now, so I don’t know

okay, I’ve officially been doing too much XMPP. when I type x in my browser bar, the first suggestion is not xkcd.com anymore, but xmpp.org.

jonas’, I keep you even more busy :) check the inbox :)

holy smokes, I knew you were one of those russian spammers!!!! (jk)

jonas’, haha, two more to come! (but not now)

jonas’, this time when you find the problems with the document tell me and I will fix them prior to the Council discussion, in order not to waste their time

zinid, okay

I have a vague feeling that the council members are on council because they like wasting their time with taking apart protocols...

really?

I thought they mostly take apart XSF rules :)

zinid: those are a special kind of protocol.

Ge0rG, yeah, I learnt recently SEX is also a protocol

how is it going btw? where is the protoxep?

"how is your SEX life by the way"

zinid: I haven't decided yet whether to make it a proto XEP. Need to read through OX and MLS first

Also, surprisingly, some people dislike the name

ha, I told you. The wrong community. Rename to FAP.

btw, I tried to read the MLS I-D, but fell asleep after a few minutes. Really not my stuff.

zinid, very satisfying thanks 🤣 🤣 🤣

Maranda, hello ;)

Good mornin' 😸

Wasn't SEX the thing that was "post operational transform" and could transfer an empty XML doc in only 9,000 stanzas and half a gig?

dwd: SXE?

Oh, yes. That's the one.

What sort of amazing compression were you using to get that into half a gig?

Zash, Good point - these days, compression isn't allowed Because Security.

Looking at Outreachy. "FOSS communities need to have secured funding for at least one intern ($6,500)", that's.. not going to be possible?

Somewhat out of reach for ~3 people working in their free time without any formal organization, yeah.

Ok so outreachy for diversity in this community is a no-go, unless companies can chime in maybe.

Something something discrimination against poor FOSS projects!!!!11!1eleven

Yeah, so like 90% of FOSS

I'm trying to understand one thing about Jingle. For example I have got a session-initiate request. iq-from and "initiator" are different for some reason. so I send back iq ack to iq-from and then session-accept to initiator jid. What if for example I receive content-add from initiator jid as iq-from now instead of original iq-from? How should I treat it?

pep.: Tho, we could still talk to them

Do you know who to ping and how to approach them?

Not really

pep.: "Hi, we're a bunch of FOSS projects around the open IM protocol XMPP" and invite the organizers to some event to talk about encouraging diversity in FOSS projects. Like a sprint or somesuch.

Something along those lines

How to reuse Matrix marketing 101: https://ppjet.bouah.net/im-protocols-interop.png (I took a few liberties)

oh lawd

https://en.wikipedia.org/wiki/Xmpp#Connecting_to_other_protocols

Matthew, (please stop me if you're not the right matthew), I'm looking at the Matrix and the french state talk, and you list a set of features for the protocol, notably e2ee _and_ server-side search. How does that work?

What do you look at if your server doesn't have plain data

the idea is that you run your own server somewhere trusted to index the data

https://github.com/matrix-org/matrix-search

Those ee2e freaks never cease to amaze me. First they trust no one and demand end to end encryption. Them they understand that total privacy is kinda inconvenient, so they are willing to totally compromise their e2ee to have nice fearures back

(the idea is also to run the server clientside; eg in the desktop apps, to have better control over the plaintext)

we’re not trying to do homomorphic encryption or anything fancy

Right, so it's more of a client-side feature ish

Does the data come from the client, or is the indexer actually plugged on the network

Why not run just your own server and not bother with e2ee?

Andrew Nenakhov: because it sucks if someone pwns your server

and servers tend to be slightly easier to pwn than endpoints

I don't actually agree with the last comment, but I do with the previous one.

Got stats on that?

And as a server admin I'd like to not be able to see my users' data

pep.: in the linked project, the data comes from the network

we are having second thoughts on whether that’s the right design

You mean than android phones that can pe pwned with a png oic?

zash: just common sense that it’s easier to pwn some random crappy homerun vps than an iphone

Matthew, you mean an iphone not pin-locked? :P

also, it’s easier to find servers and they’re tend to be turned on all the time

and they gather more data and metadata than a client

*shrug*

> And as a server admin I'd like to not be able to see my users' data I mean, the only security threat that e2ee helps is server operators. If you are your own operator you dont need to protect against yourself

So nothing to back that up?

Andrew Nenakhov, not sure if I read your message correctly, but yeah, as a server admin I'd like not to be able to sell (give) my users' data to any government or whatever

> And as a server admin I'd like to not be able to see my users' data That's easy. Never look at it.

read my last message

Oh right. Do not host servers with data from strangers.

What have strangers to do with that

Don't host servers to begin with. Or use computers! Moving into the woods and growing potatoes is the final solution to all tech problems!

If you have a known people who's data might be asked for retrieval by government, you'd better not have them on your server in the first place

why?

This obsession with encryption is unhealthy. :-/

If users want e2ee, fine

people who are in trouble with their governments do not have the right to use IM?

Just dont ask for server to nicely find your chats from last year by fulltext

Matthew, do you have resources describing what e2ee in matrix protects from (what goals)? or can you summarize it quickly?

As a person who was visited by FSB thugs 4 times last year pressing me to have backdoors in our app... I do more than most people to protect rights of users to use IM

I also know that 80-90% of e2ee users in russia are junkies

Beware selection bias :)

Like, literally, junkies and their drug suppliers

So what

It's not worth giving options to the other 10%?

So im allergic to e2ee demands. )) Because i have a very accurate mental image of an average user

Also worth noting, that junkies are MUCH more inclined to pay for their privacy than those other 10%

I'm not denying that what I'm seeing is also crypto junkies. That doesn't mean I'm excluding legimate cases entirely, (whatever legitimate means)

pep.: https://docs.google.com/spreadsheets/d/1Bv2Pf4rz62nB8omDFoolRmONmU47zIeGewJBbPeADoM

Thanks

is some brief notes on matrix’s e2ee threat model from a while back

Somehow these who love freedom and are offended by idea of being spied upon rarely pay. I guess that has to do with them treating e2ee as their constitutional right

And noone pays for constitutional rights)

(btw, it’s a pleasure to be having constructive xmpp<->matrix convo; bridging ftw)

:)

I know right, bridging ftw: https://ppjet.bouah.net/im-protocols-interop.png :P

i saw :p

Do you know a bit about OMEMO, and do you think that'd be compatible with Olm?

As in, is that even bridgable

Didn't they differ in some tiny part like IV or somesuch?

that would suck

hmm, the certificate changes incorporated in synapse 0.99, that seems a bit meh. Judging how people never update their deployment, you're basically cutting off federation with them on a 3-months (was it?) notice

Where did I read that again

It was in the talk IIRC?

There's a bit in the talk, but not the notice period

https://github.com/matrix-org/matrix-doc/pull/1711/commits/f30e6851127874739659ffe2b2c211c4db6e50f0#diff-14fe96e0952d0411db3e9ecbbddce789R53 I remember reading this

Or my browser remembers, rather

"Once everybody has migrated off to v3 rooms, we'll be killing off v1 rooms", so, almost never :x

Let me tell you about Groupchat 1.0

I was going to mention it yeah

That was "The old thing" back when MUC was first written

the difference is perhaps that we’re in position to upgrade a bit more ruthlessly and proactively

and can massively cheat because there’s only one usable server

That surely simplifies lots of things. You're not in control of every deployment though

I think that's the biggest barrier

I'm sure we could have done that in 2003 when jabber.org was still The Place

of course, but if we ship synapse 1.0 that refuses to talk to self-signed certs and put it on the disproportionately large matrix.org, i suspect folks would get around to chucking a real cert on their servers

and we‘ve given a month for folks to sort themselves out

it remains to be seen if that’s enough

but i’d prefer to set a fast tempo for this sort of thing, and coincide it with the 1.0 etc

and yes, i bet in the jabber.org days you could have done similarly for xmpp

and yes, i know omemo, and it is compatible with olm (in fact the omemo xep at one point adopted olm). but that doesn’t help when the underlying protocols are entirely different

I was just curious to know if it was compatible enough to work over a bridge

it’s like saying that xmpp and nntp both use tls, and then being sad when they can’t talk to one another

There comes a point where if you do that, you would be cutting yourself off from the wider federation.

no, you always have to reencrypt e2e over a bridge

or have a multihead client

yeah ok

Matthew: I don't think the low-level protocol matters for that. OTR "works" over any transport.

zash: only because otr is used for plain text payloads

It'll be more a matter of how what bits goes into OMEMO and OLM and whether they can come out the other end

Matthew: So is OMEMO

whereas omemo and olm encrypt entire objects aiui

or at least olm does

No, OMEMO is jsut the plain text body

oh, ok

That's one of the problems some people have with it

well, i guess we could do a dialect of olm which only encrypts the plaintext body, but that’s a bit bleurgh

Right

especially as matrix is about syncing objs rather than IMs in the end

we’re going to take a look at replacing olm and megolm with mls, anyway

which at least might get everyone on the same ratchet

but you’d have the same problem of what layer you encrypt at

yeah

in terms of the body or the whole stanza (or event in matrix terminology)

What I'd like to have, is a client implementing the component interface, and being able to run bridges etc., this way I wouldn't care about these bridges decrypting and reencrypting

basically, e2ee + bridging = sadpanda

unless you run the bridge clientside, but then you’re basically back at a multiheaded client again.

and the cycle continues

loads of the matrix bridges are built that way tho (whatsapp, imessage, signal etc)

inderd

and indeed

i don’t think it’s that unreasonable to say that if you want e2e you should be on the same network tho

assuming you have bridged public rooms and insecure bridged dms

I don't think it's reasonable to say that to users. They don't understand they're using Matrix or XMPP and they really don't care. Or at least my mom doesn't :)

That basically goes with all more advanced native features

then perhaps there is more use for a “just the payload” e2e dialect

for bridging purposes

When doing bridges, there'll usually be things that can't be translated. So you end up with the lowest common denominators.

have filed https://github.com/matrix-org/matrix-doc/issues/1871 fwiw

:)

Matthew: nice to see you in this room :) Had some enlightening talks with matrix folks at fosdem

Very excited that you seem to have found some solutions to the "fingerprint flood problem" :D

cool :) glad you were able to sync with folks on our side

and yup, cross signing is looking promising

although we still have some thinkos in the current spec

and need to do a 3rd rewrite

https://github.com/uhoreg/matrix-doc/blob/cross-signing/proposals/1680-cross-signing.md is the 2nd iteration of it

in case there’s anything of interest there.