XSF Discussion - 2019-08-07

This sounds like it will also affect xmpp clients on ios https://www.theinformation.com/articles/facebook-hit-by-apples-crackdown-on-messaging-feature

Do you have a version of the full article

pep.: isn't that the full article?

There's a registration wall.

oh, sorry. didn't realize it's paywalled if not opened from https://news.ycombinator.com/item?id=20629567

> Right now, the calling feature in these apps runs in the background even when it’s not in use I wasn't aware this was still the case.

Holger: at least you can send silent pushes this way.

Yes. I thought that was the only remaining VoIP privilege.

Isn't the gist here that if you use another protocol for non-calling features, you're fine? Like, say, XMPP. It reads to me as if they want to limit piggybacking stuff on WebRTC data channels, or something.

ralphm: I've interpreted it as further limiting background activity, maybe also silent notifications

Well, indeed if they are no longer allowing async pushes waking up an app without bothering the user, that's bad.

I'm very curious how you'd implement muting conversations in such a scenario.

server-side

I guess.

But how does that *improve* privacy?

is that the goal?

Well, that's the story

I didn’t read the article and just suspected they want to make life for app developers harder and reduce battery drain

https://www.theverge.com/2019/8/6/20757710/apple-ios-iphone-restrictions-messaging-apps-internet-voice-calls-voip

The suspicion is that Facebook is using running-in-background to gather data.

Which sounds very unlike Facebook, to me 😈

The video from WWDC seems to nicely sum up the various use cases and how do achieve this in the future. For 'us' it probably means that we should differentiate between different kinds of pushes (e.g. message v.s. call) in XEP-0357 and/or server-triggered pushes.

It might be that servers need to know more about e.g. when a call is made to resources known to be dormant. There are more reasons to revisit Jingle calling in the face of multiple resources, some of which might be offline, which are badly covered by the way a jingle call is initiated with iq stanzas, and this is one of them.

didn’t we have a XEP which does that with messages instead of IQ?

That's not optimal in my opinion.

what would be optimal?

Placing calls to bare JIDs and have servers take care of it.

but E2EE!!!

ralphm, what would the server do that clients can’t do with carbon-copy, MAM and messages?

E.g. know that this is about a call and not something else, and wake up clients properly.

Also I don't see how this is a problem for e2ee.

Caps/disco#info based magic? Or some opt-in subscription thing?

I don’t either, but the E2EE mafia will jump on this with "but the metadata!"

Well, if you don't want servers to know that calls are being signalled, then, well, I guess you can't use XMPP directly. You might negotiate a p2p XMPP stream but then you have metadata about that.

Zash: huh?

> E.g. know that this is about a call and not something else, and wake up clients properly. Only wake up voip-capable clients for voip requests eg?

I think we need explicit client existence, rather than magic, for these. ✏

Persistent serverside device tracking?

Yes.

And management thereof.

Indeed

And as you have to register clients for push notifications, you might want to define it there.

I think you might care about this for more than push, so extracting it out probably makes sense.

Sure

The push registration might become a side-effect.

I think the push registration then probably becomes an action on a registered device.

s/on/against/ whatever.

and then we can finally have per-device credentials

I am more and more convinced we need servers to have more smarts on behalf of the clients. This goes from call setup to pubsub subscriptions (including MIX).

hasn’t that been the idea of XMPP from the beginning?

Well, as in all technology, there always the pendulum swinging between thin and fat clients.

Thin client and E2EE is kinda tricky tho

(see also X11 v.s. wayland)

Or earlier X11 vs later X11

Zash: yes, but at least with registered devices, you could potentially know about a fix set of keys to encrypt against.

fixed

I'm myself rather skeptic about the viability of e2ee in a dynamic multi-device setup, including server-side archiving, and potentially web based clients.

Me too.

*ubiquitous e2ee

OTR works just fine here ;)

Mandatory E2EE everywhere always as some people seem to demand, doesn't seem to be compatible with how I see XMPP

I personally explicitly disable e2ee in my clients, and keep being reminded of it when I get another of those messages saying that a particular clients could show the real message.

client could not

I went as far as to make my server reject publishing of OMEMO keys so that me testing various clients wouldn't trick my contacts into encrypting everything, thus rendering everything unreadable.

:-D

Zash: Doesn't seem compatible with how I see *messaging*, not just XMPP.

Well, yeah.

If I create a PR for a XEP to fix a typo should I add a new revision field?

also I wonder why we only put initials there and not a name :)

Seve, don’t forget to re-apply :)

Yes, yes! Alex also told me :D Thank you :)

👍

So, on the topic of moving jdev, another week or more has gone by, no reply from stpeter

i dont think there will be something happening on jabber.org anytime soon

could we move the chat to muc.xmpp.org?

I don't think I'd be opposed to this

"Move" would entail a few things: "forcing" the current jdev members to relocate, updating the website, and everywhere that mentions jdev

It's not a simple thing to do, unless we actually destroyed the current MUC (which I don't think would be sensible), it's not going to disappear overnight

Destroying and leaving a tombstone with a redirection is kinda neat 🙂

i dont think the software that currently runs on jabber.org would allow setting a tombestone

but who knows, no not detroying just setting the subject, to -> We moved to jdev@muc.xmpp.org

Yes, change the subject, change all references and let time sort things out.