XSF Discussion - 2019-08-07

  1. neshtaxmpp has joined
  2. Zash has left
  3. mimi89999 has left
  4. pdurbin has joined
  5. mimi89999 has joined
  6. pdurbin has left
  7. xnamed has left
  8. lskdjf has left
  9. neshtaxmpp has left
  10. neshtaxmpp has joined
  11. andy has joined
  12. murabito has joined
  13. Yagiza has joined
  14. andy has left
  15. pdurbin has joined
  16. neshtaxmpp has left
  17. Lance has left
  18. pdurbin has left
  19. Lance has joined
  20. winfried has left
  21. winfried has joined
  22. pdurbin has joined
  23. adityaborikar has left
  24. adityaborikar has joined
  25. winfried has left
  26. winfried has joined
  27. curen has joined
  28. jcbrand has joined
  29. jubalh has joined
  30. waqas has joined
  31. jubalh has left
  32. Nekit has joined
  33. LNJ has joined
  34. neshtaxmpp has joined
  35. jubalh has joined
  36. pdurbin has left
  37. pdurbin has joined
  38. Mikaela has joined
  39. jubalh has left
  40. valo has left
  41. curen has left
  42. valo has joined
  43. jubalh has joined
  44. jubalh has left
  45. pdurbin has left
  46. jubalh has joined
  47. karoshi has joined
  48. Lance has left
  49. waqas has left
  50. jubalh has left
  51. sonny has joined
  52. Zash has joined
  53. larma has left
  54. cookie has left
  55. larma has joined
  56. sezuan has left
  57. sezuan has joined
  58. sezuan has left
  59. sezuan has joined
  60. moparisthebest has left
  61. moparisthebest has joined
  62. Ge0rG This sounds like it will also affect xmpp clients on ios https://www.theinformation.com/articles/facebook-hit-by-apples-crackdown-on-messaging-feature
  63. sezuan has left
  64. sezuan has joined
  65. sezuan has left
  66. sezuan has joined
  67. sezuan has left
  68. sezuan has joined
  69. Andrew Nenakhov has joined
  70. debacle has joined
  71. Andrew Nenakhov has left
  72. Andrew Nenakhov has joined
  73. Andrew Nenakhov has left
  74. jubalh has joined
  75. pep. Do you have a version of the full article
  76. intosi has joined
  77. Ge0rG pep.: isn't that the full article?
  78. Kev There's a registration wall.
  79. Ge0rG oh, sorry. didn't realize it's paywalled if not opened from https://news.ycombinator.com/item?id=20629567
  80. jubalh has left
  81. 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.
  82. jubalh has joined
  83. Ge0rG Holger: at least you can send silent pushes this way.
  84. Holger Yes. I thought that was the only remaining VoIP privilege.
  85. debacle has left
  86. pdurbin has joined
  87. sonny has left
  88. Nekit has left
  89. Nekit has joined
  90. pdurbin has left
  91. edhelas has left
  92. edhelas has joined
  93. COM8 has joined
  94. Nekit has left
  95. COM8 has left
  96. debacle has joined
  97. Nekit has joined
  98. Zash has left
  99. sonny has joined
  100. andy has joined
  101. mimi89999 has left
  102. mimi89999 has joined
  103. lumi has joined
  104. Zash has joined
  105. lskdjf has joined
  106. Douglas Terabyte has left
  107. Douglas Terabyte has joined
  108. sonny has left
  109. goffi has joined
  110. intosi has left
  111. intosi has joined
  112. pdurbin has joined
  113. sonny has joined
  114. pdurbin has left
  115. jubalh has left
  116. jubalh has joined
  117. intosi has left
  118. Dele (Mobile) has joined
  119. Dele (Mobile) has left
  120. jubalh has left
  121. jubalh has joined
  122. intosi has joined
  123. andy has left
  124. intosi has left
  125. 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.
  126. andy has joined
  127. igoose has left
  128. igoose has joined
  129. intosi has joined
  130. Ge0rG ralphm: I've interpreted it as further limiting background activity, maybe also silent notifications
  131. ralphm Well, indeed if they are no longer allowing async pushes waking up an app without bothering the user, that's bad.
  132. ralphm I'm very curious how you'd implement muting conversations in such a scenario.
  133. jonas’ server-side
  134. ralphm I guess.
  135. ralphm But how does that *improve* privacy?
  136. jonas’ is that the goal?
  137. ralphm Well, that's the story
  138. jonas’ I didn’t read the article and just suspected they want to make life for app developers harder and reduce battery drain
  139. ralphm https://www.theverge.com/2019/8/6/20757710/apple-ios-iphone-restrictions-messaging-apps-internet-voice-calls-voip
  140. intosi has left
  141. Kev The suspicion is that Facebook is using running-in-background to gather data.
  142. Kev Which sounds very unlike Facebook, to me 😈
  143. 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.
  144. jubalh has left
  145. 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.
  146. xnamed has joined
  147. jonas’ didn’t we have a XEP which does that with messages instead of IQ?
  148. ralphm That's not optimal in my opinion.
  149. jonas’ what would be optimal?
  150. ralphm Placing calls to bare JIDs and have servers take care of it.
  151. jonas’ but E2EE!!!
  152. jonas’ ralphm, what would the server do that clients can’t do with carbon-copy, MAM and messages?
  153. ralphm E.g. know that this is about a call and not something else, and wake up clients properly.
  154. ralphm Also I don't see how this is a problem for e2ee.
  155. Zash Caps/disco#info based magic? Or some opt-in subscription thing?
  156. jonas’ I don’t either, but the E2EE mafia will jump on this with "but the metadata!"
  157. 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.
  158. ralphm Zash: huh?
  159. 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?
  160. Kev I think we need explicit client existance, rather than magic, for these.
  161. Kev I think we need explicit client existence, rather than magic, for these.
  162. Zash Persistent serverside device tracking?
  163. Kev Yes.
  164. Kev And management thereof.
  165. ralphm Indeed
  166. ralphm And as you have to register clients for push notifications, you might want to define it there.
  167. Kev I think you might care about this for more than push, so extracting it out probably makes sense.
  168. ralphm Sure
  169. ralphm The push registration might become a side-effect.
  170. Kev I think the push registration then probably becomes an action on a registered device.
  171. Kev s/on/against/ whatever.
  172. jonas’ and then we can finally have per-device credentials
  173. 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).
  174. jonas’ hasn’t that been the idea of XMPP from the beginning?
  175. kokonoe has left
  176. ralphm Well, as in all technology, there always the pendulum swinging between thin and fat clients.
  177. kokonoe has joined
  178. Zash Thin client and E2EE is kinda tricky tho
  179. ralphm (see also X11 v.s. wayland)
  180. jubalh has joined
  181. Zash Or earlier X11 vs later X11
  182. ralphm Zash: yes, but at least with registered devices, you could potentially know about a fix set of keys to encrypt against.
  183. ralphm fixed
  184. 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.
  185. Zash Me too.
  186. jonas’ *ubiquitous e2ee
  187. jonas’ OTR works just fine here ;)
  188. Zash Mandatory E2EE everywhere always as some people seem to demand, doesn't seem to be compatible with how I see XMPP
  189. 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.
  190. intosi has joined
  191. ralphm client could not
  192. pdurbin has joined
  193. 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.
  194. ralphm :-D
  195. winfried has left
  196. winfried has joined
  197. jubalh has left
  198. pdurbin has left
  199. goffi has left
  200. jubalh has joined
  201. lovetox has joined
  202. Chobbes has joined
  203. Chobbes has left
  204. Chobbes has joined
  205. jubalh has left
  206. jubalh has joined
  207. Kev Zash: Doesn't seem compatible with how I see *messaging*, not just XMPP.
  208. Zash has left
  209. jubalh has left
  210. intosi has left
  211. ralphm Well, yeah.
  212. jubalh has joined
  213. UsL has left
  214. Chobbes has left
  215. jubalh has left
  216. jubalh has joined
  217. Zash has joined
  218. jubalh has left
  219. jubalh has joined
  220. lovetox has left
  221. kokonoe has left
  222. kokonoe has joined
  223. pdurbin has joined
  224. lovetox has joined
  225. neshtaxmpp has left
  226. pdurbin has left
  227. jubalh If I create a PR for a XEP to fix a typo should I add a new revision field?
  228. jubalh also I wonder why we only put initials there and not a name :)
  229. igoose has left
  230. igoose has joined
  231. eevvoor has joined
  232. mr.fister has left
  233. afrogeek has joined
  234. jonas’ Seve, don’t forget to re-apply :)
  235. jubalh has left
  236. Lance has joined
  237. Chobbes has joined
  238. Seve Yes, yes! Alex also told me :D Thank you :)
  239. Alex 👍
  240. neshtaxmpp has joined
  241. adityaborikar has left
  242. adityaborikar has joined
  243. Lance has left
  244. ziggys has joined
  245. karoshi has left
  246. karoshi has joined
  247. ziggys has left
  248. Lance has joined
  249. sezuan has left
  250. neshtaxmpp has left
  251. xnamed has left
  252. xnamed has joined
  253. pdurbin has joined
  254. kokonoe has left
  255. lskdjf has left
  256. lskdjf has joined
  257. kokonoe has joined
  258. pdurbin has left
  259. Dele (Mobile) has joined
  260. Dele (Mobile) has left
  261. Daniel has joined
  262. eevvoor has left
  263. jubalh has joined
  264. Dele (Mobile) has joined
  265. Dele (Mobile) has left
  266. xnamed has left
  267. xnamed has joined
  268. mr.fister has joined
  269. jubalh has left
  270. wojtek has joined
  271. mr.fister has left
  272. adityaborikar has left
  273. adityaborikar has joined
  274. pdurbin has joined
  275. wojtek has left
  276. Yagiza has left
  277. wojtek has joined
  278. pdurbin has left
  279. lskdjf has left
  280. neshtaxmpp has joined
  281. Nekit has left
  282. adityaborikar has left
  283. Lance has left
  284. Lance has joined
  285. adityaborikar has joined
  286. Daniel has left
  287. Daniel has joined
  288. adityaborikar has left
  289. adityaborikar has joined
  290. Steve Kille has joined
  291. Lance has left
  292. debacle has left
  293. Lance has joined
  294. rion has left
  295. rion has joined
  296. debacle has joined
  297. neshtaxmpp has left
  298. eve has left
  299. eve has joined
  300. lovetox So, on the topic of moving jdev, another week or more has gone by, no reply from stpeter
  301. lovetox i dont think there will be something happening on jabber.org anytime soon
  302. lovetox could we move the chat to muc.xmpp.org?
  303. jubalh has joined
  304. pdurbin has joined
  305. Tobias has left
  306. winfried has left
  307. winfried has joined
  308. pdurbin has left
  309. jubalh has left
  310. wojtek has left
  311. LNJ has left
  312. murabito has left
  313. Tobias has joined
  314. adityaborikar has left
  315. xnamed has left
  316. xnamed has joined
  317. MattJ I don't think I'd be opposed to this
  318. MattJ "Move" would entail a few things: "forcing" the current jdev members to relocate, updating the website, and everywhere that mentions jdev
  319. 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
  320. wojtek has joined
  321. wojtek has left
  322. Chobbes has left
  323. Zash Destroying and leaving a tombstone with a redirection is kinda neat 🙂
  324. lovetox i dont think the software that currently runs on jabber.org would allow setting a tombestone
  325. lovetox but who knows, no not detroying just setting the subject, to -> We moved to jdev@muc.xmpp.org
  326. Lance has left
  327. jubalh has joined
  328. Lance has joined
  329. Ge0rG Yes, change the subject, change all references and let time sort things out.
  330. Nekit has joined
  331. pdurbin has joined
  332. karoshi has left
  333. karoshi has joined
  334. pdurbin has left
  335. neshtaxmpp has joined
  336. waqas has joined
  337. jubalh has left
  338. xalek has joined
  339. wurstsalat has left
  340. Douglas Terabyte has left
  341. Mikaela has left
  342. debacle has left
  343. igoose has left
  344. igoose has joined
  345. igoose has left
  346. igoose has joined
  347. Douglas Terabyte has joined
  348. igoose has left
  349. igoose has joined
  350. karoshi has left
  351. waqas has left
  352. rion has left
  353. rion has joined
  354. Lance has left
  355. lovetox has left
  356. Lance has joined
  357. pdurbin has joined
  358. pdurbin has left
  359. Douglas Terabyte has left
  360. Douglas Terabyte has joined
  361. Nekit has left
  362. neshtaxmpp has left
  363. neshtaxmpp has joined
  364. alameyo has left
  365. alameyo has joined