XSF Discussion - 2018-11-01

Tobias: I was looking at XEP-0385 (Stateless Inline Media Sharing). Have you considered sending multiple media files at once? Would it be supported by adding additional <file/> elements?

WOuldn't that be multiple <media-sharing/> elements? Or maybe even references depending.

Multiple messages, multiple media-sharing or multiple file

That probably needs to be specified

But inside a single message would probably be best. Multiple messages already works

Sure, I'd prefer a single message in my use case

I'd prefer a single message to carry multiple 0184 delivery receipts, but that's not what the XEP allows...

I'm a bit surprised also by the use of XEP-0372 References here. In my thinking, References was meant to annotate a previous message. This seems to leave off the uri attribute to refer to the current one. I think that use case has not been properly defined.

In fact, in my use case, there wouldn't necessarily be a part of the text to be reference.

d

More like the 'add attachment' button in many messengers.

Ge0rG: maybe XEP-0333 is more appropriate for you?

ralphm: I want per message receipts, but with a more efficient delivery

I'm not sure if I can see the use case, but yeah, then that doesn't help

Anyway, I was really looking at Tobias' spec only right now.

The use case is after mam sync / fetching offline messages. You need to ack a bunch of incoming messages, and the respective payloads are just ids, wrapped into a bunch of boilerplate

ralphm, No, references were always meant to be capable of referring to the current message. For hyperlinky stuff.

> The use case is after mam sync / fetching offline messages. You need to ack a bunch of incoming messages, and the respective payloads are just ids, wrapped into a bunch of boilerplate Ge0rG: I think we either talked about this before or I independently had the thought of just bundling multiple receipts in a single message

Ge0rG: but XEP-0333 just marks the last one, so that covers the use case

ralphm, no it doesn’t, because you can’t be sure that all messages between two markers actually arrived ✏

However in reality at least the bandwidth overhead of multiple messages vs one would be negligible if we had proper compression

We should really revisit the compression xep

And make it secure ™

dwd: ah, I guess the references XEP needs to point this out then. Nevertheless, it doesn't seem useful for when you don't have a particular part of the message to reference, when sending media.

Someone Should™

jonas’: arrived at the user or at his server?

What happens if the receiving users archive acks messages when they are saved into the archive?

ralphm, both

Zash: right

> would be negligible if we had proper compression You could start with https://github.com/mgp25/Chat-API/wiki/FunXMPP-Protocol :-)

And call it WhatshAPPening

looks like they invented a stripped-down version of EXI

jonas’: almost

I expect EXI to be more useful than generic compression in the general XMPP case actually

Without the negotiation bits? ("these are the namespaces I'll be using")

EXI is more involved tho

(Re almost exi)

Zash, that’s true

> I expect EXI to be more useful than generic compression in the general XMPP case actually But arguably a lot harder to implement

probably

"FunXMPP" is closer to a fixed compression dictionary IIRC

Especially since the xep is apparently garbage

if there are no ready-to-use libs

Zash, yes, which is also what EXI does

hah. This one is much better than exi for chat! http://cvs.schmorp.de/Net-Knuddels/Net/Knuddels/Dictionary.pm?revision=1.5&view=markup

jonas’: EXI generates those from schemas tho

Zash, true

why compress protocol when you can compress the chat message content

fippo: wut

I sense sarcasm

But fwiw I'd love to play with exi if I can get a server dev on board

jonas’: sure hope so, since that's the opposite of what we want here

zash: this module is not a joke even. i think the knuddels stuff came up in the late 90s, mostly in germany. they were alive until a recent databreach

is there a lua-exi?

jonas’: nope

pity

And EXI seems complex enough that I'd rather use a library than NIH it

yes please

is there even any floss implementation of EXI?

Deprecate it! It's too complex you'll never get it right! /s

that libexi is "status: planning" on sourceforge, whatever that means

Thanks Firefox, I really did mean to go to http://EXIstentialcomics.com/

jonas’: a Java one

But that's literally the only one I believe

http://exip.sourceforge.net/ ?

daniel: I'm interested in EXI, actually, but no clue where we'd start to get something sensible (and no cycles to do anything immediately).

Compression - be it exi or an improved compression xep - would make for a good summit topic

That's a good idea

wasn't Arc Riley working on EXI stuff?

Guus: yes. He was the one who told us that the xep is garbage

(probably not his exact words)

Where's he off to anyways? Haven't seen him in ages.

vanished after last year’s board elections essentially

hope they’re alright…

You could define a zlib-safe that requires flushing between every stanza (or when to/from changes in some way)

Zash, Am I right in thinking Prosody has built-in support for JWT authentication for BOSH/WebSocket connections?

dwd: What makes you think that?

What does that even mean?

Zash, I was under the impression that Jitsi used something like that.

Zash, Of course, I could so easily be wrong.

Sounds like an reasonable approach to 'fixing' that xep

dwd: Jitsi might have added custom code (it did so for a number of things, iirc)

Seems to have, indeed.

dwd: https://github.com/jitsi/lib-jitsi-meet/blob/master/doc/tokens.md

that's likely it

Yeah, I just found that myself.

Isn't the issue with compression and encryption that a MiM can inject bits of information in messages going to an entity that are sure to be returned, to learn about the dictionary?

ralphm: Yes, like iq id attributes.

ralphm, Sorta. Compression oracles work by inserting known plaintext into a compression stream. So in our case, the compression stream is the entire session, so an attacker just sends messages to see if they can guess what's been sent before.

ralphm: If you flush between stanzas, that goes away

ralphm, But an attacker has to be able to see the compressed/encrypted stream, to count octets. I've generally considered this quite a hard attack.

like on a mobile device?

You usually need a *lot* of requests to get actual secrets out

ok, I had no idea how practicle an attack like this is

https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-and-xmpp-2-crime-and-breach/

also, I'm particular curious about server-to-server connections in this regard

ralphm: https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-and-xmpp-2-crime-and-breach/

jonas’: ha

ralphm, By which I mean, if an attacker has got to the point that they've got full access to your network traffic *and* is willing to expose themselves by sending traffic over tyour XMPP session as well, they're getting pretty desperate.

ninja’d

I know that document, but sure

dwd, sending traffic to ones XMPP session is not that hard using a botnet. I get a lot of unsolicited traffic all day.

that’s not *that* suspicious anymore

jonas’, Sure, but the attacker *also* has to have visibility over your TCP sessions.

that’s true

But are the amounts of traffict required to do an actual attack small enough to evade admins being annoyed by the bandwidth usage?

I wouldn’t count on admins thwarting an attack

Zash, Maybe. Depends what they're trying to discover. It'd be relatively simple to find out, for example, if you were in this MUC by sending you traffic including the room's jid. But then, it's far easier to just join the MUC and look... ✏

Another way to fix this is to have a fixed dictionary

Zash, That's not how zlib works.

dwd: There are other compression libraries

dwd: And you can sorta fake it by feeding it a dictionary before every ... chunk .. somehow.

Zash, Sure. But then you're only able to compress, say, the XML. So you'd be into EXI territory.

dwd: Picking say zstandard and training a dictionary on some XMPP data ought to be a lot easier to do than implementing all of EXI

Zash, Better solution of course is to use a constant-bandwidth transmission medium. :-)

Not necessarily, the spec could say that the dictionary must contain "@yourserver.com" or similar (assuming we want to target large rosters and assume that most people will be using the same server as their friends)

dwd: So padding all stanzas to the 1GB mark?

But I doubt a fixed dictionary is actually practical; interesting to think about though.

Kev: 10MB and you have a deal

Kev, No, just transmitting at a constant rate, and including padding.

Kev, It works quite well on radios. :-)

Whitespace flood instead of ping?

like ssh does for keystrokes? :)

jonas’: REAL TIME TEXT?

!!

SamWhited: Could do something where the client downloads and caches a dictionary on connect. Then it can be tuned to the server and stuff. More complexity tho and closer to EXI

(Can you tell that I just found `zstd --train ...` ?)

ooh, yah, that's interesting. It would be fun to think more about what sort of policies the server could create that way

Zash, interesting

I say "policies", but I guess you don't have to target anything if you do that. Just train it on lots of streams and see what the most common stuff is.

And you'll end up leaking private data in your dictionaries.

Trade-offs

So exclude bits of the stream you don't want it to see

Start training after stream negotiation, drop IDs, messages probably won't matter because if a phrase is reused enough it's probably not private, etc.

If we knew which bits that was, we could do nice compression.

... and that's basically what FunXMPP is

Fair

Pre-defined dictionary

With common things like "<message " and such

Zash, except with zstd, there would be a standard-ish way to translate that dictionary

and we wouldn’t be limited to keep XML metacharacters in place

for example, 'from="' could be one token in the dict

all known xmlns="..." etc

yupp

Hate to interrupt, but…

XSF Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

'<a xmlns="urn:xmpp:sm:2" h="' :-)

here

0. Welcome and Agenda

quorum?

MattJ sent regrets

Guus?

I"m here

Yay

(no agenda items from me)

I have Elections and FOSDEM

and ED?

nyco?

Ok

1. FOSDEM

FOSDEM/Summit is for SCAM?

We've requested a stand again.

(just informative)

oh great

thx a lot

(what nyco said)

Also, we've secured the location for the Summit

I intend to make reservations for the annual dinner later this week

We now need to start really inviting people to come and look at hotel deals

also, I'm assuming that last years hotel arrangements were ok? I'll redo those too, then

That's it for me on this.

one thing

now that you raised the topic

last year, we, as in the XSF, invited three people to summit and fosdem, sponsoring them. I dubbed them 'young potentials', I think.

do we want to do something like that again this year

and if so, who? Last year, we extended an invitation to gsoc students. We did not participate in gsoc this year.

what was the outcome of this?

We had two students attend, iirc

how much were we attractive?

both of them are still active in the ignite realtime community

at least one of them mentioned that he'll be going to FOSDEM again this year.

so we might wanna do it again, I'd go for it...

I kind of like the concept of doing such sponsoring, but I can't immediately identify candidates for this iteration.

Do you have suggestions for candidates?

Let the records reflect that suggestions are welcome.

Let's put it back on next weeks agenda

k

2. Elections

With 3 days left, the list is wanting

we're at 4 candidates for board, 3 for council. All sitting candidates, I think

Indeed

Sorry, lagging here, but from the peanut gallery, did any of the young hopefuls remain active in the standards community, or just for a particular project?

We've moved on, nevermind. As you were.

Kev: Guus can still answer that one.

Kev: one is still active, afaik.

Should we be worried about Council specifically? Three people is really meager

Paul / Vanitas

It's only two, actually, with one intending to apply but hasn't yet.

I was going to take a year off, but I'll throw my hat into the ring again now.

Kev: well, if you mean: there page isn't actually there yet, we then also only have 2 for Board. *shame*

I wonder if there are people that are inclined to run, but are hold back for some reason

Shall I sent another reminder?

yes, please, I think

Ok.

Well, Alex just did one?

Last Friday, yes.

today is good, because it's Thu, and still a week day

Right

3. Executive Director

Another Council application in.

I think the relevant people now know that we have an election. I don't think it's a matter of pointing that out. Maybe we can persuade them to actually run, in some way though.

reminder at -48h, -24h, 12h, 6h, 1h, 30 min... 😉

We haven't had one since Peter resigned this post. There's been question on needing one, and to be honest, maybe we don't.

Thanks Kev

Ralph, we briefly discussed this last week. I offered to take over from Martin, in doing an inventory of tasks/responsibilities.

which I wanted to do after we actually meet with Peter, for this and financials, which is another 'todo' that's been outstanding for to long..

Ok

if we don't have an ED, then do we need to modify the bylaws? or we just elect a ghost ED?

I think Peter stated that he intended to resign as soon as we had a replacement.

as he's not actually doing anything in the role currently, I prefer having this status-quo over undertaking the massive operation that is rewriting the bylaws.

What I've also seen done is that the Chair of the Board is appointed in such role in the absense of a candidate.

but, we should move on this. We should have, ages ago.

(like in the company I currently work at)

ah I like that the chair is ED as well

*the idea*

ralphm, if that works with our bylaws (I doubt it, for reasons), we might want to wait until next board picks a new chair then.

Right, I'm not sure myself, it is just something that popped up.

worth considering, nonetheless.

I think the ED is appointed by the Board, so I don't think it conflicts, but I'm happy to hear thoughts from the floor on this, before actually suggesting we do this.

ED being on Board would seem inappropriate to me, even if it's allowed.

Given the ED is used to break deadlocks in the Board.

"If the Board consists of an even number of Directors, the Executive Director of the Corporation shall be empowered to cast a tie-breaking vote (...)" complicates matters.

(what he said)

Kev: indeed.

The issue is that a) I haven't seen this been used in this corporation, b) I have no real other suggestions.

But I'm happy to discuss with Guus and Peter.

Let's move on for now

*tap*tap* is this thing still on?

Everyone moved on.

ralphm usually swings his mighty hammer before he does. 🙂

4. EOB?

AOB?

ennie, how nice and Dutch of you 😛

now.

no*

5. Date of Next

+1W

6. Close

Thanks all!

XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

thanks!

thx everyone!

ralphm: what was wrong with him/her?

Nothing, but jonas’ applied self-mute-ation earlier.

(which might or might not have been a ploy to get out and play)

j.r: there was a discussion going just when I interrupted to have our Board meeting, so he said he would go silent

Still missing an applicant for Board?

Seve: we can always use more

Seve: https://wiki.xmpp.org/web/Board_and_Council_Elections_2018

"Zash> jonas’: EXI generates those from schemas tho" not necessarily. i was told that it would perform also well without schemas, although I wonder if it would suffer from the same side channel based attacks as zlib compression

"Kev> Sorry, lagging here, but from the peanut gallery, did any of the young hopefuls remain active in the standards community," I'd say vanitasvitae is active, he wrote a mail to standards@ not to long ago, but go no reply/response back, so I'd say the standards community is the entity being inactive here ;)

some numbers on the stream compression ratio (numbers are "bytes saved" in percent from the perspective of the client; i.e. tx == from client to server, rx == from server to client): aioxmpp test suite, sync_flush only (XEP-0138 as written): 40% rx, 20% tx aioxmpp test suite, full_flush after each stanza: 25% rx, 20% tx JabberCat startup (lots of mucs, lots of avatars), full flush after each stanza: 25% rx, 12% tx JabberCat startup (lots of mucs, lots of avatars), sync flush: 36% rx, 12% tx sync vs. full is executed on both sides (client and server) ✏

these are to be taken with a grain of salt due to the rather narrow use-cases