XSF Discussion - 2018-04-06

Yes, people get scared when hear Jabber, as UsL said, people then to make 'do not like face' saying 'the old old chat thing??' (in case they know it)

I'm still waiting for a viable alternative proposal that will work without a multi million marketing campaign

Ge0rG: first migrate the planet to xmpp.org ^^

so I replied in operators@ instead of here.. : S

still havent had my morning coffee :O

I have more and more spam each days

UsL: you might associate Jabber with a low-quality implementation, but at least you know what it is about.

my only solution for now is to blacklist more and more servers

I frown upon people not taking their morning coffee ceremony seriously.

(afk, getting coffee)

Guus: have a nice weekend

Weekend? We've got an entire workday ahead of us 🙂

Guus: in that case you don't take your morning coffee ceremony sufficiently serious.

Broken records are broken.

yes, that was the implied joke.

https://www.yourtango.com/sites/default/files/styles/header_slider/public/display_list/friday.jpg

Just one coffee??!!

s/the//

My office is also my kitchen, where the espresso machine is. 😊

Deliberately keeping my coffee machine two floors down from my office ;)

yes, that is the case. Still, jabber and the lightbulb feels dated compared to xmpp and the xmpp logo. Is it supposed to be two horns? Or two of those ancient looking baskets that Miss Fortuna held. Cornucopia. Had to look it up.

haha, I'll try to coffee before talking hence forth

UsL: nobody knows I think.

There was a long logo discussion last year

the description fits though: "commonly a large horn-shaped container overflowing with produce, flowers or nuts."

: D

nuts!

The only thing I can agree on. We are all nuts.

that settles it. The logo depicts two cornucopias

🤔

🤯

I love the XMPP logo

Feels modern

(subjective I know)

Too bad that normal people can't stop going "what" whenever you mention "ECS-AM-PEE-PEE" who knows maybe it's the two final P ™️. Thoughts?

Maranda: just ask them for their JID then.

😎

I think the logo form is based on the 'X' in XMPP.

UsL was till on the way out of his trip with "cornucopias and stuff" me thinks

s/till/still/

Maranda: so you are processing urine of former military police personnel? That's noble.

The pointy bit of speech balloons?

Ge0rG 🤨 that statement didn't 🖥

E_CONTEXT

Maranda: ex MP pee.

Ohh

😆

Members of Parliament?

Zash, flow: Seems I'm missing something regarding "Blocking of subscription request denials"? What's the problem with the server (1) handling my 'unsubscribed' presence as usual but (2) not forwarding it to the requester?

flow: > on subsequent incoming requests from the blocked entity have the server send an error (or rejection) presence. This would clearly violate 0191 ("For presence stanzas (including notifications, subscriptions, and probes), the server MUST NOT respond and MUST NOT return an error"), no?

Zash: those, too.

Holger, I'm not sure if we talk about the same thing anymore. What I have in mind is: 1) A sends sub request to B; 2) B blocks A; at 2 A's server could reject the sub request from the blocked entity

What is the rationale of xep191 becoming a presence blackhole?

Holger: Possibly an implementation detail. Gets complicated for one plugin to let another do some of the processing for an event but not other.

Holger, you seem to talk about: 1) A sends sub request to B; 2) A blocks B; 3) B rejects A's sub request

In which case I'd also say that the server should simply process the rejection (unsubscribed) as usual

winfried, Ge0rG: I wont be able to make todays meeting, sorry

flow: You send me a sub request. I block you, then I deny that request. I get an error because I blocked you, and then I get the request sent to me every time I sign in with no way to do anything about it.

Holger: ^

flow: No I didn't talk about the latter case but about the one Zash repeated now.

I can easily see this being meh to implement. I was just wondering whether I got the scenario wrong. Maybe I didn't after all :-)

Might be a case of "being modular is hard"

You get an error if you send a stanza to an entity you have blocked?

> If the user attempts to send an outbound stanza to the JID, the user's > server MUST NOT route the stanza to the JID but instead MUST return a > <not-acceptable/> error [...]

bummer

I suppose you could argue that presence management stanzas are not outbound stanzas.

Zash: So process the stanza and send an error :-)

I wonder what's the rationale behind that

Zash: Hah I thought I'm kidding but seems that's ejabberd's behavior.

Probably does the trick in practice.

Looks like Prosody would send the not-acceptable error to itself, not to the user, if presence handling was done before blocking.

Talking to yourself can be healthy.

We're already breaking another MUST so that you don't get a ton of not-acceptable in response to normal presence broadcasts, in case you've blocked a bunch of subscription=both|from contacts

what's wrong with that not-acceptable? It allows the client to show the contact as "bad"

Zash: What MUST are you breaking in that case?

That same one I quoted above

It doesn't distinguish between presence stanzas sent from the server and those sent from the user.

Ge0rG: Hmmm

Can we persist error messages in offline storage/MAM?

Zash: A presence broadcast qualifies as an attempt "to send an outbound stanza to the JID"?

How do you know your denial was processed

GDPR meeting in 5min!

Uh-oh!

I'm totally unprepared.

Sorry, will be late and have to leave early

!

jonasw, ?

pep.: jonasw> winfried, Ge0rG: I wont be able to make todays meeting, sorry

okay

Shall we start anyway? Have a look at what's left

winfried, how long do you have

Me?

Where is gdpr meeting? Here?

Appart from the LQ{1,2}, I think we've covered the C2S case pretty much already?

Anu, yes

Anu: here and now, though we are missing some people

https://wiki.xmpp.org/web/GDPR

Also dealing with baby so I might lurk

hi Anu! :)

I'm taking minutes of whatever this will be :p

I’ll try to participate to the best of my ability

It looks like we are missing two participants, including our chair.

I can try to chair a bit, but I'm rather unprepared, so brace for a very loosely organized session

I guess we'll do it short and plan another date

winfried, ready?

I think we have multiple points that still need to be worked out: Q1.1d List legal grounds for the processing - that didn't feel quite finished to me, especially regarding federation Q1.1e Analyse possible consequences Q1.2: What consequences does the GDPR has for the XMPP server operators Q1.3: What can/should the XSF do with it?

have to leave at 14:00 CEST (35 minutes from now)

Ge0rG: yes, S2S / federation is still open

I've briefly looked at GDPR work in the IETF, but didn't find something like a WG, it's just a topic in different sub-orgs

Anu wanted to add more lawyer questions, which I'd like to hear as well

Anu: yes, please!

Maybe we can ask Board for some budget regarding those.

1: what level of logging is legal on xmpp servers

2: what info (presence/server logs) counts as pii and has to be purged when right to be forgotten is involved

Anu: I think that server logs are pretty well covered under recital 49

Anu: +1 @ Ge0rG

http://www.privacy-regulation.eu/en/recital-49-GDPR.htm

Anu: pii is also quite well defined

winfried: is it really?

I think there is still no clear consensus whether IP addresses are PII or not ,)

Ge0rG: they are

(but IPadresses are a nice edge-case)

I was also told they are. But yeah they might not identify just one individual

Anu: the questions are also very technical. You'd have to explain to the lawyer how XMPP works, first.

For the process right now: I propose we take a look at the tasks at hand check if we can do some of them before the next meeting and plan a next meeting...

sure

https://wiki.xmpp.org/web/GDPR

I added 'TBD' on some places Q1.1d still needs some more details and from Q1.1e everything is work in progress.

winfried: yeah. We should talk about federation now

I feel Q1.1e is going to be even more speculation than the rest

pep.: yes

pep.: I think there are some non-speculative parts in e. Like how to do a data retention policy, and how to implement the right to be forgotten

Ge0rG: Yes, starting with Q1.1b on S2S

Ge0rG, ok I wouldn't have put right to be forgotten in 1.1e

Next TBD Q1.1c on S2S

so let's do S2S 1.1b and c

k

pep.: 1.1e is *very* speculative

for 1.1b S2S: - s2s meta-data (IP addresses, hostnames, sessions, probably server logs) - I don't think the GDPR applies - user meta-data (presence, subscriptions, message routing) - user content (messages, pubsub, ...)

s2s meta-data, I think GDPR is out as well, it's not somebody's private info

agree

- MUC history, MUC MAM

Ok

anything else for 1.1b?

can't think of anything right now

I think that covers pretty much everything

remote components

include pubsub in there then

there is component access to roster, I don't know which kind of data is a transport allowed to access there

3: when an xmpp opeator is fined is it based on personal income if they are non profit?

remote_vibrator.tilanus.com? ;-)

Anu: 3 -> no

Ge0rG, I would consider that as standard s2s

Anu: the fine is max(0.04*turnover, 200k€) - so even if you are broke, you can be fined 200k€

Who can add this to the wiki? One TBD down then!

winfried, I'm taking the minutes

pep.: https://xmpp.org/extensions/xep-0321.html#request_roster

pep.: thanks!

Ge0rG, hmm

Remote Roster Management requires explicit user consent, and provides information about it, so I suppose this is well covered by the existing legal framework

However, I'd like to have Remote Roster Management explicitly listed as a data type

Ge0rG: +1

good catch

cool

next: Q1.1c

- transfer to an other controller

- archiving (MAM, MAM on MUC)

- s2s meta-data - typically just inside of server logs, so R49 probably applies - user meta-data: all transfer requires (implicit) user consent - by joining a MUC or sending a message to somebody or accepting a subscription

I had a legalese 101 question, what is meant by "third-party country" in chapter 5? Does that mean it only applies when transfering data to *other* countries?

pep.: non-EU

pep.: transfer to non-EU is also a possible processing here....

So they always use this third-party country term from what I gathered, where is transfer within EU entites defined then

pep.: No, 5 is about transfer out the EU

I see

winfried: does it matter if we do s2s inside or outside the EU?

Ge0rG: Yes

then we need to separate that

outside chapter 5 applies, inside not

That's going to be fun

*big time*

Zash, be prepared to see a mod_gdpr appear at some point :p

pep.: before may the 25th :-P

heh

I have to leave soon :-(

new appointment?

Ok, we should do date of next

I'm free anytime. monday same time?

wfm

though monday better a bit earlier

What time?

starting between 9:00 and 12:00 CEST works the best for me

I can starting 10:30CEST

jonasw: any possibility?

err that's 9:30am here ><

I'll have to get up

But ok

winfried, jonasw is not here. will try to ping him during the weekend

pep.: thanks

So monday 10:30CEST it is then?

yes

cool, *bang*

CU!

Ge0rG, I would rename your "user meta-data" above in Q1.1c to "user data", it's talking about messages etc.

pep.: no, it's message routing metadata

Ok so we still have to cover user content then, that works

Though winfried mentioned MAM etc.

MAM contains both

https://cryptpad.fr/code/#/1/edit/Zc1c+aBtFP-49TYSX0T+7g/VcSdjDmU9rC0crMKwQyiehe9/ what I have for now. I'll have another read after lunch

Meeting still happening?

Anu: nope

Aw ok

Looks like it was productive

Mod gdpr will probably be needed

Honestly gdpr is the biggest gift to walled garden monolithic messaging systems. Unless you control the whole stack it’s hard to be compliant

I’m wondering if xmpp will even be legal. It was made from another time and merrily leaks ip addresses to other servers

E.g push servers get device ips

Anu: push servers like Google and Apple? They have your IP anyway

Anu: I don't see how XMPP is different from email

No push like push.monal.im that use Apple to push to your device

I know chatsecure and conversations have similar push servers

Anu: Registration with the push service for Conversations works without revealing the IP address, though.

Anu: push.monal.im talks to your XMPP server and to Apple APNS, not to the client

Yeah it's quite similar to email and I don't think they'd want to get rid of this. Also I didn't see anything federation specific in Google's policies

The out of band registration will log the device ip on the push server

(It's done via XMPP, i.e. routed over your server.)

Anu: In your case, yes.

Anu: that's not part of the XEP, is it?

Right, the XEP doesn't specify how to register.

Or I’m mixing protocols :( hold on

Let me see

so should I switch my father-in-law from ChatSecure to Monal now?

Anu: AFAIK clients register against push.monal.im via HTTP and thereby reveal their IP address (short of using some proxy), yes. I'm just saying it doesn't have to work this way, and doesn't for Conversations (but also for ChatSecure IIRC).

Not yet . I haven’t published the libsignal stuff

Anu: no need for E2EE, just chat and http-upload

not even MUCs

Bah you know I I’m tired when I don’t remember how my own push service works :(

Oh right it’s s2s in with token info

Tokens should be suitably pseudoanonymized

Anu: The actual registration step is via HTTP, AFAIK :-)

Ok

The rest call

Yeah.

https://github.com/tmolitor-stud-tu/mod_push_appserver

Phew I thought I was thinking of another protocol

:-)

monday 10:30 CEST wfm if we don’t draw it out too long, Ge0rG, winfried

I’d like to leave at 11:30 CEST

No joke I have like four of them swirling in my head and they are all usually very similar

Holger: is there a TL;DR about setting up push on an xmpp server the right way?

Ge0rG: For ejabberd you enable mod_push and mod_push_keepalive, but that's probably not what you meant?

jonasw: cool

Holger: yeah, in retrospect it was pretty dumb to ask you things about my server.

I think the process on prosody isn't much harder

Yeah it’s pretty straightforward on prosody

That’s what I use

I'm not sure if it's ChatSecure then that's borked, or if my father-in-law can't properly use his phone.

mod_cloud_notify now supports the mod_push_keepalive magic AFAIK, at least partly.

I think for chatsecure you might want to look at the patched mod_cloud_notifiy

Hm or maybe not.

Don't ask me why that isn't mainline though

daniel: patched where?

It is now.

Well a variant of it.

since when?

(The same variant I'm going for with ejabberd.)

So many questions. All off topic

Is the keep alive to keep the connection open?

Holger: a variant that is compat with Chatsecure?

daniel: Yes.

Cool

Why?

Anu: it's to check if the connection is still alive and if not send a push as a wakeup signal

Anu: It's to keep the stream management session open, yes. Mostly to make push notifications work for MUC messages.

Isn’t the whole point that we use the push to signal time to wake up

ah

Oh man so do you guys see me going offline constantly?

Anu: The client disconnects but the session remains alive.

Ah cool that’s exactly what I need!

I’ve only been using Monal with muc and push

Anu: For this to work, you must close the TCP session without terminating the XMPP stream.

Yes

And resume it ok wake up

The next thing we need to design: MUC notification filtering, where the mobile client doesn't need to be joined all the time but can connect and MAM-sync when the user is highlighted

Thats what I do now but user showing up as offline when I close the tcp connection has been driving me nuts

Anu: https://mail.jabber.org/pipermail/standards/2016-February/030925.html and https://mail.jabber.org/pipermail/standards/2016-February/030925.html

Anu: I'm not sure whether mod_cloud_notify can be configured to do that.

prosody will keep the session visible as online as long as smacks doesn't kill the zombie

I’m thinking about a completely non invasive fix for this on the client side. Ditch offline, it’s not really a thing anymore. It doesn’t solve the muc issue though

Ge0rG: But there's no hack to increase the timeout for the push case?

Anu: "offline" is a limited use case, but "dnd" is rather important, I'd say

Ge0rG: Wouldn't you just silence your phone rather than hoping your contacts will respect that status?

Holger, but letting contacts know that they won’t have success with sending you a message is probably nice?

also maybe a thing which lets a sender override that dnd silence if and only if they are in some whitelist

I think "last activity" is a better indicator for success chances.

Holger: my jabber goes dnd when I silence my phone.

e.g. "people from the family group may circumvent phone dnd (raise a priority notification) if asked for"

jonasw: I mean in theory I see your point but in practice presence status is just always wrong.

Holger, is it?

Holger: I think "last activity" is a nice addon to proper dnd signaling

Ge0rG, if I had that setting, I would always be dnd :)

it would be great if the presence was reflected by the actual DND status of the phone.

Ge0rG: My phone does the same, but I'm often available despite my phone being quiet. It's just always wrong.

(not sure if this is lineageos specific, but it has a neat DND mode where you can say either priority only, alarms only or total silence for N hours)

(or by time)

jonasw: that lineageos mode is fucking with my brains.

how?

there used to be (silent+alarms|vibration|normal) and then they split up the first one into two different ones

and one of them ended up also silencing the alarm.

Really, who on earth wants their alarm silenced?

I say it's a valid use case

there is probably a use-case for that.

think small children wihch might be woken up or something, meetings of indefinite duration, …

...coming late to work.

that only happened when it -- I think -- didn’t reset the alarm volume after I accidentally triggered total silence

My phone is permanent silenced haha

I don’t even know what my alert tones are

But that might be a very narrow use case.

I honestly think one problem for xmpp is that there are mobile and desktop clients. Mobile will almost never be offline or away

Desktop might be.

Anu: there are people shutting down wifi and mobile data over night

Really? That’s a thing?

Anu: and there are people going outside of network coverage for hours

Anu, it is a thing, I’m one of them

my worst case is to take long phones when on 2G

my phones battery doesn’t like if conversations is in 20 MUCs overnight for no reason.

jonasw: but it is there for a reason!

Haha

you could miss an xmpp rant!

Anu: I'm not sure the presence status is really that useful on the desktop either.

I’ve been thinking a lot about my ui choices and how they are rooted in 90s tech

I still have status under the username in the contact list

Ge0rG, I can read up on XMPP rants in poezio :>

No one pays status anymore

Posts

It was a proto Twitter

Anu: Kev suggested to rework status from a per-client thing to a per-account thing. It would make more sense then

Ge0rG: Would the result be much different from how clients show presence today?

I have my alarm silenced by the way

Holger: probably not

I wake up just with the phone's vibration (although I usually wake up some minutes before it starts)

pep.: Make it so

Not exactly sure what would go in there though

Anu: is there a Monal iOS beta program?

`forbid_non_compliant_s2s = true` :o

Anu: if I "delete this account" from Monal, will it delete the account on the server or just the client setup for it?

hm. the latest version is a year old and doesn't show contact names, but shows multiple JIDs per contact.

EU is becoming a mass of demented nonsense, well it was already but now it's even more.

Without the vomiting lagalese included. 😠

You'll have to deal with that vomiting legalese anyway

Not all of that pepe, I'm sure that 80% is as usual incomprehensible blah blah that ends in a possible "compression ratio" of 3/4

I started implementing SIMS (https://xmpp.org/extensions/xep-0385.html) in my XMPP client. The XEP tells me that data sent using Bits of Binary (https://xmpp.org/extensions/xep-0231.html) is stored on the server, but I can't find any definition of a protocol to send such data to the server. Also e.g. prosody says that the Bits of Binary XEP is server independant and thus works even if the server doesn't support it. I also can't find an implementation for ejabberd. Can somebody explain that? :D

hey LNJ, you are working on Kaidan, right?

Ge0rg: will not delete from server.

There is a beta I can invite you to

Ge0rg: Yep, that's right

LNJ: you basically just put base64 stuff in the same stanza

Anu: yes please

On the root level of the stanza

So of the root level of the SIMS Stanza?

No on the root level of the message stanza

Ah ok

And then the Sims reference references that

But isn't the BoB XEP saying to not include the data directly, if it's larger than ~1 KiB?

Yew

Yes

Ok, so I'll just ignore that fact ...

:D

Ignore that. But keep them reasonable small I guess

daniel: is SIMS the new OOB?

The entire stanza including mam overhead should be less than 10k bytes

I was planning on generating thumbs with 2kb or 3

Ok then it should into 10 kB

* should fit

Just to be clear you could request bob from the other party in an iq request as well

That defeats the stateless part though

But bob would allow you to do that

Ge0rG: some people want it to be the new oob

I'm not entirely convinced

Partially because of the weirdness I've just talked about

References has weirdness, SIMS does, OOB does too (in the IQ section)

But that's not very nice if the other use has to be online. But I'll implement that as well, just for the case. :D

Madness everywhere

People are weird

I'm relatively convinced that the way I just described it is the way it is supposed to work (sticking it in the root of the message). However that is entirely unclear after reading the xep

daniel: will you replace OOB with SIMS? References?

Replace. Probably not. Maybe I do both. I'm mostly in it for the thumbs

While other people are in it for the mime tag

*most other people

But ux wise this opens a can of worms on the Conversations side

That's why i have been pushing this off

hm, the last argument of yours on this I heard was "how does it work with e2ee"?

daniel: btw, how does Conversations handle non-picture uploads like PDF, or pictures that are attached instead of recompressed?

it doesn't. but i don’t care. i'm just doing thumbs different in omemo

so, virtually everywhere?

:-)

public mucs

so you’d auto-download/show content in public MUCs?

that's where thumbs will be used most of the time anyway

because they are not auto downloaded

unlike the rest of conversations

ah I wa sthinking you were replacing auto-download with auto-show-thumbs-and-tap-for-full-version

mhhh maybe not. i still think i'll be autodownloading files by default

users can always turn that of. and having thumbs might make that more attractive

haven't thought about that before you brought that up

maybe auto-fetch thumbs and download full versions when and only while the conversation is in view?

yeah maybe. first things first though. implement thumbs and aftewards we can maybe think about changing the auto download defaults

Ge0rG, things that exceed the auto download size currently have a normal button that says 'donwload pdf document'

or download mime/type if it's not well known

(auto fetching thumbs)

and files for which i do not have a thumbnail after download will just display an open $foo button

you leak your IP if you are browsing images in any random web forum, so meh.

daniel: if you plan to auto-download, there is no need to pursue thumbs. Except for huge files

Ge0rG, *made in legalese*

yes like i said the way it currently works they will mostly be shown in mucs

where i don't have auto download

but they open the door to changing the auto download behaviour as jonas and i were just discussing

plus fancy

LNJ: do you happen to have a Kaidan MUC?

Well ... yes, but after file uploads

AH .. you mean a channel

LNJ: yes. A place where I can bother you without going through github

Yes there was one at kaidan@conference.siacs.eu .. but I'd prefer a new on the new kaidan.im server

Wait, I'll create one ..

Thanks, LNJ.

xmpp:kaidan@muc.kaidan.im?join

... wait need to configure my dns

Haven't used muc before on that server

yay it's back https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02

they also thankfully mention hiding ALPN using the same mechanisms