This sounds like it will also affect xmpp clients on ios https://www.theinformation.com/articles/facebook-hit-by-apples-crackdown-on-messaging-feature
sezuanhas left
sezuanhas joined
sezuanhas left
sezuanhas joined
sezuanhas left
sezuanhas joined
Andrew Nenakhovhas joined
debaclehas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
jubalhhas joined
pep.
Do you have a version of the full article
intosihas joined
Ge0rG
pep.: isn't that the full article?
Kev
There's a registration wall.
Ge0rG
oh, sorry. didn't realize it's paywalled if not opened from https://news.ycombinator.com/item?id=20629567
jubalhhas left
Holger
> 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.
jubalhhas joined
Ge0rG
Holger: at least you can send silent pushes this way.
Holger
Yes. I thought that was the only remaining VoIP privilege.
debaclehas left
pdurbinhas joined
sonnyhas left
Nekithas left
Nekithas joined
pdurbinhas left
edhelashas left
edhelashas joined
COM8has joined
Nekithas left
COM8has left
debaclehas joined
Nekithas joined
Zashhas left
sonnyhas joined
andyhas joined
mimi89999has left
mimi89999has joined
lumihas joined
Zashhas joined
lskdjfhas joined
Douglas Terabytehas left
Douglas Terabytehas joined
sonnyhas left
goffihas joined
intosihas left
intosihas joined
pdurbinhas joined
sonnyhas joined
pdurbinhas left
jubalhhas left
jubalhhas joined
intosihas left
Dele (Mobile)has joined
Dele (Mobile)has left
jubalhhas left
jubalhhas joined
intosihas joined
andyhas left
intosihas left
ralphm
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.
andyhas joined
igoosehas left
igoosehas joined
intosihas joined
Ge0rG
ralphm: I've interpreted it as further limiting background activity, maybe also silent notifications
ralphm
Well, indeed if they are no longer allowing async pushes waking up an app without bothering the user, that's bad.
ralphm
I'm very curious how you'd implement muting conversations in such a scenario.
jonas’
server-side
ralphm
I guess.
ralphm
But how does that *improve* privacy?
jonas’
is that the goal?
ralphm
Well, that's the story
jonas’
I didn’t read the article and just suspected they want to make life for app developers harder and reduce battery drain
The suspicion is that Facebook is using running-in-background to gather data.
Kev
Which sounds very unlike Facebook, to me 😈
ralphm
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.
jubalhhas left
ralphm
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.
xnamedhas joined
jonas’
didn’t we have a XEP which does that with messages instead of IQ?
ralphm
That's not optimal in my opinion.
jonas’
what would be optimal?
ralphm
Placing calls to bare JIDs and have servers take care of it.
jonas’
but E2EE!!!
jonas’
ralphm, what would the server do that clients can’t do with carbon-copy, MAM and messages?
ralphm
E.g. know that this is about a call and not something else, and wake up clients properly.
ralphm
Also I don't see how this is a problem for e2ee.
Zash
Caps/disco#info based magic? Or some opt-in subscription thing?
jonas’
I don’t either, but the E2EE mafia will jump on this with "but the metadata!"
ralphm
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.
ralphm
Zash: huh?
Zash
> 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?
Kev
I think we need explicit client existance, rather than magic, for these.✎
Kev
I think we need explicit client existence, rather than magic, for these. ✏
Zash
Persistent serverside device tracking?
Kev
Yes.
Kev
And management thereof.
ralphm
Indeed
ralphm
And as you have to register clients for push notifications, you might want to define it there.
Kev
I think you might care about this for more than push, so extracting it out probably makes sense.
ralphm
Sure
ralphm
The push registration might become a side-effect.
Kev
I think the push registration then probably becomes an action on a registered device.
Kev
s/on/against/ whatever.
jonas’
and then we can finally have per-device credentials
ralphm
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).
jonas’
hasn’t that been the idea of XMPP from the beginning?
kokonoehas left
ralphm
Well, as in all technology, there always the pendulum swinging between thin and fat clients.
kokonoehas joined
Zash
Thin client and E2EE is kinda tricky tho
ralphm
(see also X11 v.s. wayland)
jubalhhas joined
Zash
Or earlier X11 vs later X11
ralphm
Zash: yes, but at least with registered devices, you could potentially know about a fix set of keys to encrypt against.
ralphm
fixed
ralphm
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.
Zash
Me too.
jonas’
*ubiquitous e2ee
jonas’
OTR works just fine here ;)
Zash
Mandatory E2EE everywhere always as some people seem to demand, doesn't seem to be compatible with how I see XMPP
ralphm
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.
intosihas joined
ralphm
client could not
pdurbinhas joined
Zash
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.
ralphm
:-D
winfriedhas left
winfriedhas joined
jubalhhas left
pdurbinhas left
goffihas left
jubalhhas joined
lovetoxhas joined
Chobbeshas joined
Chobbeshas left
Chobbeshas joined
jubalhhas left
jubalhhas joined
Kev
Zash: Doesn't seem compatible with how I see *messaging*, not just XMPP.
Zashhas left
jubalhhas left
intosihas left
ralphm
Well, yeah.
jubalhhas joined
UsLhas left
Chobbeshas left
jubalhhas left
jubalhhas joined
Zashhas joined
jubalhhas left
jubalhhas joined
lovetoxhas left
kokonoehas left
kokonoehas joined
pdurbinhas joined
lovetoxhas joined
neshtaxmpphas left
pdurbinhas left
jubalh
If I create a PR for a XEP to fix a typo should I add a new revision field?
jubalh
also I wonder why we only put initials there and not a name :)
igoosehas left
igoosehas joined
eevvoorhas joined
mr.fisterhas left
afrogeekhas joined
jonas’
Seve, don’t forget to re-apply :)
jubalhhas left
Lancehas joined
Chobbeshas joined
Seve
Yes, yes! Alex also told me :D Thank you :)
Alex
👍
neshtaxmpphas joined
adityaborikarhas left
adityaborikarhas joined
Lancehas left
ziggyshas joined
karoshihas left
karoshihas joined
ziggyshas left
Lancehas joined
sezuanhas left
neshtaxmpphas left
xnamedhas left
xnamedhas joined
pdurbinhas joined
kokonoehas left
lskdjfhas left
lskdjfhas joined
kokonoehas joined
pdurbinhas left
Dele (Mobile)has joined
Dele (Mobile)has left
Danielhas joined
eevvoorhas left
jubalhhas joined
Dele (Mobile)has joined
Dele (Mobile)has left
xnamedhas left
xnamedhas joined
mr.fisterhas joined
jubalhhas left
wojtekhas joined
mr.fisterhas left
adityaborikarhas left
adityaborikarhas joined
pdurbinhas joined
wojtekhas left
Yagizahas left
wojtekhas joined
pdurbinhas left
lskdjfhas left
neshtaxmpphas joined
Nekithas left
adityaborikarhas left
Lancehas left
Lancehas joined
adityaborikarhas joined
Danielhas left
Danielhas joined
adityaborikarhas left
adityaborikarhas joined
Steve Killehas joined
Lancehas left
debaclehas left
Lancehas joined
rionhas left
rionhas joined
debaclehas joined
neshtaxmpphas left
evehas left
evehas joined
lovetox
So, on the topic of moving jdev, another week or more has gone by, no reply from stpeter
lovetox
i dont think there will be something happening on jabber.org anytime soon
lovetox
could we move the chat to muc.xmpp.org?
jubalhhas joined
pdurbinhas joined
Tobiashas left
winfriedhas left
winfriedhas joined
pdurbinhas left
jubalhhas left
wojtekhas left
LNJhas left
murabitohas left
Tobiashas joined
adityaborikarhas left
xnamedhas left
xnamedhas joined
MattJ
I don't think I'd be opposed to this
MattJ
"Move" would entail a few things: "forcing" the current jdev members to relocate, updating the website, and everywhere that mentions jdev
MattJ
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
wojtekhas joined
wojtekhas left
Chobbeshas left
Zash
Destroying and leaving a tombstone with a redirection is kinda neat 🙂
lovetox
i dont think the software that currently runs on jabber.org would allow setting a tombestone
lovetox
but who knows, no not detroying just setting the subject, to -> We moved to jdev@muc.xmpp.org
Lancehas left
jubalhhas joined
Lancehas joined
Ge0rG
Yes, change the subject, change all references and let time sort things out.