XSF Discussion - 2018-04-10


  1. Ge0rG

    Kev: is there any progress on the 0050 PRs?

  2. Kev

    There isn't.

  3. Ge0rG

    Kev: any more ideas regarding the pidgin re-addition to the client list?

  4. Kev

    I haven't given it any thought, do I need to?

  5. Ge0rG

    I wonder if it's possible to instrument something like shodan to search for XMPP servers.

  6. MattJ

    Sure

  7. Ge0rG

    I mean, we need to send the client banner first, right?

  8. MattJ

    I've used it to discover Prosody instances

  9. Ge0rG

    MattJ: oh, that's interesting. Tell me more about it.

  10. MattJ

    I don't know exactly what it sends, but it triggers an error response

  11. MattJ

    Prosody's particular error message is unique, so searching for it yields results

  12. Ge0rG

    `GET / HTTP/1.0`?

  13. MattJ

    Quite possibly

  14. MattJ

    I suspect it understands XMPP somewhat though, but obviously you can't determine the host from the IP address so it still doesn't work

  15. pep.

    gdpr meeting in ~5

  16. jonasw

    what

  17. jonasw

    crap

  18. jonasw

    I totally forgot

  19. jonasw

    I need to marinate some meat first, so I’ll be a bit AFK-ish

  20. pep.

    it's 12:30CEST right?

  21. jonasw

    yeah

  22. pep.

    hehe

  23. jonasw

    taking the laptop with me

  24. jonasw

    Ge0rG, winfried, ping

  25. winfried

    Guys, sorry, I will be the available in 10 minutes

  26. pep.

    I'll put stuff on the wiki then, I sent the minutes quite late yesterday

  27. jonasw

    sounds good

  28. Ge0rG

    10 minutes for me as well

  29. jonasw

    what a perfect fit

  30. Ge0rG

    pep.: 👍

  31. pep.

    Hmm, so we already had a bit on 1.1c for s2s in the wiki, not as detailed

  32. winfried

    here I am

  33. Ge0rG

    AOL!

  34. winfried hears an echo from long ago

  35. Ge0rG

    It looks like we all might be there.

  36. winfried

    yes

  37. jonasw

    .

  38. pep.

    !

  39. pep.

    *bang*?

  40. jonasw

    baaang

  41. jonasw

    winfried, are you going to chair?

  42. winfried

    *bang*

  43. winfried

    do we have enough on 1.1a-c?

  44. pep.

    S2S outbound on 1.1c?

  45. pep.

    did we cover that?

  46. pep.

    I guess the inbound covers more or less both actually

  47. Ge0rG

    what happened to transports?

  48. winfried

    Ge0rG: yes, noticed that one too

  49. winfried

    transport will be a processing to cover in c2s too!

  50. Ge0rG

    1.1c inbound and outbound is symmetrical, i.e. there is no need to differentiate. we need to differentiate in 1.1d though

  51. winfried

    yesx

  52. pep.

    fair enough

  53. winfried

    With the note of transports, I think we should move to 1.1d, where the fun begins...

  54. Ge0rG

    winfried: do you have an update on the "third contries" part?

  55. winfried

    Ge0rG: yes

  56. winfried opens page 19 of his bible

  57. Ge0rG braces for liturgy recital

  58. winfried

    criteria: 3.2a offering services to EU citizens or 3.2b monitoring behaviour within the EU

  59. jonasw

    I’m fully here now

  60. winfried

    3.2a: just offering in english or so is not enough, but a multiple of factors like english and accepting euro's and shipping to the eu is

  61. jonasw

    winfried, what would the equivalent of "shipping" would be? not denying service?

  62. winfried

    jonasw: with a service like XMPP it is quite tricky to judge

  63. jonasw

    yeah

  64. Ge0rG

    winfried: oh, that's too broad. I was asking about s2s connections from the EU to third countries.

  65. winfried

    Ge0rG: ah, ok

  66. winfried

    Ge0rG: that one is quite clear cut, is chapter 5

  67. pep.

    First the laws of said country have to be deemed adequate right?

  68. Ge0rG

    winfried: chapter 5 is rather long. Can you provide a TL;DR, as this is going to affect s2s

  69. winfried

    chapter 5 has different grounds, adequacy is just one of them

  70. winfried

    (adequacy is art 45)

  71. pep.

    pff, I don't want to imagine an implementation for that

  72. winfried

    diving further in my bible....

  73. Ge0rG

    Ah, so transfer to "adequate" countries does not require any additional measures

  74. winfried

    Ge0rG: correct

  75. pep.

    yeah, art45

  76. pep.

    45.1

  77. winfried

    art 46: other possibilities are: Binding Corporate rules (when transfer inside one cooperation) (art 46.2b)

  78. Ge0rG

    so adequate and EU countries are the same category for s2s

  79. Ge0rG

    winfried: 46 probably doesn't apply.

  80. winfried

    Ge0rG: because?

  81. pep.

    doesn't it?

  82. pep.

    Unless you implementation forbids s2s to non-adequate third-countries

  83. pep.

    Unless your implementation forbids s2s to non-adequate third-countries

  84. Ge0rG

    winfried: or at least the contract/same-corp provisions of it

  85. Ge0rG

    unless all xmpp servers are operated by the same BigCorp

  86. pep.

    that's 47 right?

  87. winfried

    Ge0rG: correct BCR (46.2b) doesn't apply

  88. pep.

    Ah 46.2b right

  89. pep.

    that refers to 47

  90. Ge0rG

    46 is written in legalese, and I fail to parse it right now

  91. pep.

    isn't all

  92. winfried

    yeah, I really need my bible here...

  93. winfried

    46.2c is interesting: standard clauses

  94. Ge0rG

    pep.: no, other parts are more appropriate

  95. pep.

    So we're trying to figure out if we'll have to filter out s2s right

  96. Ge0rG

    winfried: I suppose 46.2c means something like safe harbor/whatisitcallednow

  97. pep.

    Or how much

  98. pep.

    And/or how much

  99. Ge0rG

    pep.: right

  100. pep.

    That is really meh. Who was talking about trying to reach email people again

  101. pep.

    See how they cope with that.

  102. winfried

    no, safe harbour is part of the EU-US adequacy decision: "if you keep to privacy shield, it s adequate"

  103. pep.

    "Hey users, you can't reach half of the planet from now on"

  104. pep.

    winfried, how is this privacy shield defined?

  105. pep.

    hmm, what about 49.1a?

  106. Ge0rG

    AFAIU third countries are also covered by user consent

  107. pep.

    yes just what I pointed out I think

  108. winfried

    privacy shield is a (before GDPR) construct to legalise EU-US transfer, saying: when keeping to privacy shield, then the protection in the US is adequate and permitted

  109. jonasw

    I’m trying to find a clue about it in the google privacy policy atm

  110. winfried

    (And Schrems finely argued it was not adequate becease the NSA was left out it)

  111. winfried

    So now al companies leave adequacy as ground and use standard clauses

  112. pep.

    I'd say article 49 applies quite a lot

  113. jonasw

    so, there’s nothing in that

  114. jonasw

    (that = google privacy policy)

  115. jonasw

    with respect to federation

  116. jonasw

    I begin to suspect that the following applies:

  117. winfried

    jonasw: you just found an interesting legal gap at google ;-)

  118. Ge0rG

    jonasw: sue them!

  119. jonasw

    1. the user has a clear intent to share a message with a recipient when they send a message. 2. it is up to the recipient how they handle the data. this includes whether they consent to it being stored on their server and for how long

  120. pep.

    winfried, they have more laywers than you will ever have

  121. jonasw

    now how that works in the light of germany’s whatsapp decision, I don’t know.

  122. Ge0rG

    jonasw: I tend to agree with you here, however... by sending a message you only show implicit consent in that the message is to be delivered to the recepient, not that it shall be analyzed to create a profile of your sex life.

  123. winfried

    pep.: yes, but for example when analysing Microsofts new terms, I found over a douzen issues that were violating EU law

  124. jonasw

    Ge0rG, that’s true, but if the receiving party consented to that?

  125. jonasw

    that’s a matter between you and the receiving party then, isn’t it?

  126. jonasw

    I mean the receiving party could also simply upload all your messages manually to some service which does that to gain some moneyz.

  127. Ge0rG

    jonasw: yes.

  128. jonasw

    so nothing which concerns server operators?

  129. pep.

    interesting

  130. Ge0rG

    jonasw: the receiving party must gain your consent to process your data.

  131. jonasw

    but that’s #notourdepartment?

  132. Ge0rG

    yes

  133. pep.

    Ge0rG, by subscribing?

  134. jonasw

    so we can simply not give a fuck?

  135. pep.

    Or joining a MUC, or ..

  136. jonasw

    I don’t think that subscription is consent for any level of advanced processing.

  137. winfried

    49.1b may be very applicable here

  138. jonasw

    not for art 9.1 type processing at least

  139. Ge0rG

    jonasw: maybe. Maybe we need to explicitly tell the user that their messages might leave the EU

  140. pep.

    winfried, if 49.1b is not enough, there's still 49.1a

  141. pep.

    Ge0rG, 49.1a then

  142. pep.

    explicit consent

  143. jonasw

    Ge0rG, mmm, I feel that this might be a reasonable assumption.

  144. jonasw

    like, if you send a message overseas, it’ll be overseas, period.

  145. jonasw

    however, it’s unclear that you might send a message overseas when I send a message to somebody who is in e.g. sweden but has an account at $USProvider

  146. pep.

    I fear users do not know if it will be overseas, but we can just state the possibility in anycase

  147. Ge0rG

    I'm pretty sure we can argue that 49.1b applies here: you have a service contract with the XMPP server, and if you want your messages to be sent overseas, the server will happily do so

  148. Ge0rG

    jonasw: $USProvider is subject to GDPR then.

  149. winfried

    pep.: my reading is you need one of 49.1a-49.1g

  150. pep.

    winfried, yes

  151. jonasw

    I think c applies

  152. pep.

    if 45 and 46 don't apply

  153. Ge0rG

    jonasw: I don't thing 49.1c applies here

  154. pep.

    jonasw, as in, contract between server operators ?

  155. winfried

    49.1c needs a contract between server operators and it needs to be in the interest of the user. Mainly the first one is problematic, the second one may be

  156. Ge0rG

    I think that 1b is better applicable here.

  157. pep.

    Well we don't have to settle on one, unless it's 1a

  158. pep.

    If both apply, great

  159. winfried

    49.1b says (more or less) and analouge to 6.1b: when it is needed to perform the request of the user

  160. Ge0rG

    Yup.

  161. pep.

    yes

  162. winfried

    and that one is quite clear: we federate and transfer on request of the user

  163. jonasw

    Ge0rG, oh indeed I misread

  164. pep.

    Indeed, I only have that s2s connection if a user requests it

  165. winfried

    49.1a feels a bit like a minefield to me

  166. Ge0rG

    So I'd argue that transfer of content is covered by 49.1b because the user wanted the content to be sent to wherever, and meta-data is covered because the user wanted to subscribe or somesuch.

  167. winfried

    Ge0rG: +1

  168. pep.

    Seems good to me

  169. Ge0rG

    It might be a good tech TODO to have that written in the data policy.

  170. pep. fires vim

  171. Ge0rG

    people that you approve as contacts will be able to see your online status.

  172. jonasw

    Ge0rG, mmm, with subcsription I’d argue that some things aren’t obvious.

  173. winfried is listening

  174. jonasw

    ah, that’s what you meant

  175. jonasw

    makes sense

  176. pep.

    jonasw, I think we ought to make them obvious in the policies

  177. Ge0rG

    jonasw: let's make a list

  178. jonasw

    Ge0rG, ack

  179. jonasw

    1. vcard avatar is always publicly visible

  180. jonasw

    2. pep avatar and other pep things are most likely visible to your contacts. what things are there, besides avatars?

  181. Ge0rG

    jonasw: vcard avatar is public data. maybe good to have a separate category for that

  182. jonasw

    3. last online timestamp, status message, online status, list of online devices

  183. jonasw

    list of online devices also means things like software version btw

  184. jonasw

    because if you know the resource, you can IQ

  185. Ge0rG

    jonasw: I think that #2 is actually well covered implicitly. If you "play a tune", you want that to be shared with your friends

  186. jonasw

    possibly

  187. jonasw

    it’s the clients job to make that explicit at least

  188. Ge0rG

    I don't want to open _that_ can of worms

  189. jonasw

    yupp

  190. jonasw

    that’s fine

  191. jonasw

    let’s focus on what must be done on the protocol/federation/server level.

  192. Ge0rG

    so we need two lists: things shared with everyone; things shared with contacts

  193. winfried

    Ge0rG: yes

  194. Ge0rG

    the latter might contain surprises to the user.

  195. Ge0rG

    with everyone = with everyone who knows your JID

  196. pep.

    And things not shared, as in credentials etc., even if obvious

  197. winfried

    Ge0rG: you can assume a JID to be publicaly known

  198. pep.

    Ge0rG, maybe define "everyone who knows you JID" a bit more? contacts, non-anon MUC owners

  199. Ge0rG

    winfried: can I?

  200. pep.

    other server operators

  201. pep.

    winfried, I don't think so

  202. Ge0rG

    "contacts, chatrooms and their server operators"

  203. winfried

    don't know if that discussion is *very* relevant here/now but in practice most people publish their JID, so they can be contacted...

  204. Ge0rG

    winfried: if you publish your JID, your JID is obviously public

  205. Ge0rG

    winfried: but what if not

  206. pep.

    I'm going to go soon-ish, starting to get hungry

  207. pep.

    This list falls under things to be transparent about in the privacy policy then

  208. Ge0rG

    pep.: yes, it's for the tech TODO

  209. pep.

    yep

  210. winfried

    +1

  211. Ge0rG

    so do we have 1.1d covered now=

  212. Ge0rG

    so do we have 1.1d covered now?

  213. winfried

    with the remark of sensitive data or not

  214. Ge0rG

    right.

  215. winfried

    (LQ1)

  216. pep.

    Ok

  217. Ge0rG

    the Sword of GDamoclesPR

  218. pep.

    Can we plan next?

  219. winfried

    yes

  220. winfried

    I will try if I can get some opinions on sensitive data in some lawyer groups I participate in

  221. jonasw

    I’m sure it’s sensitive data. I’d just like to have clarification on if simple store-and-forward (and no analysis) brings us into 9.1 realm

  222. winfried

    jonasw: exactly

  223. jonasw

    neat

  224. jonasw

    so, date of next?

  225. jonasw

    my constraints shifted and I’m unavailable thursday this week

  226. pep.

    not tomorrow if possible

  227. pep.

    Fri noon?

  228. jonasw

    friday would wfm, something like 10:30 CEST -- 11:30 CEST e.g.

  229. Ge0rG

    so friday?

  230. pep.

    I'm not available in the morning

  231. jonasw

    is 10:30 still morning at yours?

  232. pep.

    yes

  233. jonasw

    I see

  234. Ge0rG

    I'm blocked after 1300CEST

  235. pep.

    before 12 is morning :P

  236. pep.

    hmm

  237. jonasw

    mmm, I can’t promise 12:00CEST

  238. Ge0rG

    pep.: set up an alarm :P

  239. pep.

    Ge0rG, I have paid job to do

  240. pep.

    In between :p

  241. Ge0rG

    yeah, right :P

  242. winfried

    Friday I am available between 12:00 and 13:30 CEST

  243. pep.

    I can do 9:30 here, 8:30UTC

  244. pep.

    if it doesn't go more than an hour

  245. Ge0rG

    jonasw: take your laptop to the lunch break? ;)

  246. Ge0rG

    it never went more than an hour!

  247. jonasw

    Ge0rG, lunch break people won’t approach

  248. jonasw

    *approve

  249. jonasw

    wtf is wrong with me

  250. pep.

    ok so 10:30CEST

  251. pep.

    In the end

  252. jonasw

    10:30 CEST on friday, ACK

  253. Ge0rG

    winfried> Friday I am available between 12:00 and 13:30 CEST

  254. jonasw

    oh

  255. jonasw

    welp

  256. pep.

    hmm

  257. jonasw

    otherwise, next week same time as today would work for me too

  258. winfried

    OK, when doing some magic with my schedule, I can be reading from 10:30 but only be (really) active from appr. 11:00

  259. pep.

    Sure, Mon, Tue workforme

  260. Ge0rG

    we need to get this settled soon.

  261. pep.

    Fri I'm not here from 11:45 CEST to ~12:45 CEST

  262. jonasw

    I blocked friday 10:30 CEST, and I blocked Tue 12:30 CEST, I don’t care which you chose :)

  263. pep.

    Tue 12:13 CEST is fine by me

  264. winfried

    Tue wfm (more or less)

  265. pep.

    What works better?

  266. winfried

    Tue

  267. pep.

    Tue when?

  268. winfried

    after 9:30 CEST

  269. pep.

    I can do 10:30 CEST again on Tue, or anytime after that

  270. jonasw

    Ge0rG, 12:30 CEST on Tue?

  271. Ge0rG

    can do

  272. jonasw

    then it’s settled

  273. winfried

    Tuesday 12:30 CEST

  274. winfried bangs the gavel

  275. pep.

    :)

  276. pep.

    what do you call morning btw? if it's not before noon

  277. jonasw

    hmmm, in german there’s "vormittag", which awkwardly translates to pre-noon.

  278. pep.

    Ok, I know in quebec they also have this weird notion of early morning and before noon, but in france I've never heard that

  279. pep.

    (french quebec)

  280. jonasw

    it’s not particularly weird, considering we have the same for after noon

  281. pep.

    Sure. Though in usual my mornings are pretty short anyway, so just having one word is fine by me :P

  282. winfried

    pep.: lol

  283. Ge0rG

    morning is the time between your first coffee and being awake.

  284. winfried

    what's in a word!

  285. pep.

    Ge0rG, can that also include noon?

  286. Holger

    Ge0rG: So morning == afternoon?

  287. jonasw

    even more weird are the swedes, where "middag" is both dinner and noon. eftermiddag is only afternoon, but not after dinner.

  288. pep.

    :D

  289. winfried

    Ge0rG: that is never in my case, I don't drink coffee and I am never awake :-P

  290. Zash

    "förmiddag"

  291. Ge0rG

    winfried: then you have an eternal morning?

  292. pep.

    I'll try to send the minutes today. And update the wiki after that

  293. Zash

    the morning that never ends?

  294. pep. out for lunch

  295. jonasw

    Zash, do you have a highlight on "swede"?

  296. winfried

    Ge0rG: welcome in my life ;-)

  297. MattJ

    jonasw, he has a highlight on "coffee"

  298. jonasw

    MattJ, that makes sense

  299. Ge0rG

    A highlight on "highlight"

  300. jonasw

    is dwd saying "do a PR, because a vote without PR isn’t really useful at all"?

  301. jonasw

    if so, I find that hard to get from that email :)

  302. MattJ

    Well, he's not instructing, but... yes

  303. MattJ

    Voting on "X is a nice idea" and "PR X is good to merge" are different things. But I imagine Ge0rG would rather not work on a PR unless the council indicates it would be in favour of the idea of removing GC1

  304. Ge0rG

    What MattJ said.

  305. Ge0rG

    I can only imagine that Dave assumes I'm not sufficiently familiar with the Council process.

  306. jonasw

    or maybe is confused by your attempts to vote to abolish pidgin ;-)

  307. Kev

    I don't *think* Dave's mail says that.

  308. Kev

    I *think* he's just observing that the vote has no practical effect, rather that that it's a bad idea to have the vote.

  309. Ge0rG

    The practical effect will be that I'll get green lights on preparing a PR, and maybe even some Feedback From The Elders.

  310. Kev

    Ge0rG: That's not an effect of the vote, though, that's an effect of us discussing it.

  311. Ge0rG

    Obviously, a Council member could decide to lure me by +1ing the general principle vote and then blocking any follow-up PR, but I don't hope this is going to happen.

  312. Kev

    I think the vote's a sensible thing to do, as a forcing function for discussion, but it doesn't achive anything that the discussion without out a vote wouldn't.

  313. Ge0rG

    Kev: there is actually one outcome I'm looking for: Council consensus on removal of GC1.

  314. Ge0rG

    Kev: if we don't manage to achieve that consensus, I'm not going to prepare a PR.

  315. Kev

    I think that's very sensible.

  316. Ge0rG

    Which probably wasn't crystal clear from my e-mail.

  317. Kev

    And I think a vote as a forcing function on the discussion is sensible, too.

  318. Kev

    Just that it's not really *necessary*.

  319. Ge0rG

    Right.

  320. Ge0rG

    I'm painfully aware that if the vote is accepted, we'll have a second vote on the subject matter of the PR.

  321. Ge0rG

    Even my mail to standards@ can be used to discuss the motion in the wider community.

  322. Kev

    I'm against it on the basis of having been reworking M-Link's MUC implementation recently and I implemented and tested GC1 joins :p

  323. Kev

    (No, I'm not really)

  324. Ge0rG

    Kev: you have nobody but yourself to blame. I've clearly stated my goal of burning GC1 half a year ago

  325. Kev

    I'm not opposed in principle, but I do think we should have a story for how to address the 'just fix out of sync' that GC1 currently works for.

  326. Ge0rG

    Kev: "works"

  327. Zash

    Kev: It does the opposite of fixing anything.

  328. Kev

    It's not good, but it *does* work around some things at the moment.

  329. Kev

    e.g. if you've desynched then at least a presence broadcast means you start getting messages again.

  330. Zash

    Kev: You'll still be desynced

  331. Kev

    We should describe how to detect and resolve those cases at the same time as getting rid of GC1.

  332. Zash

    As in, your view of the participant list may be outdated.

  333. Kev

    Zash: You will. You'll also be receiving messages.

  334. Ge0rG

    I think I made multiple proposals back in October.

  335. Ge0rG

    I could make an even more revolutionary one: let the MUC respond to self-pings by a participant.

  336. Zash

    Kev: True. Sending a full join bundle would help in that case.

  337. Ge0rG

    Zash: not quite

  338. Zash

    Ge0rG: Assuming clients understand "ok, forget everything, here's the current state", which might need adding

  339. Ge0rG

    Zash: because you'll end up with zombie users in your participant list

  340. Ge0rG

    Zash: yes. Assuming there is some kind of marker in the stream telling the client when to forget everything from before

  341. Ge0rG

    which there isn't in the normal join bundle

  342. Zash

    Correct. So Kev says we should address that.

  343. Zash

    Returning an error and making the client rejoin does have the same end result tho, at the cost of a roundtrip

  344. Ge0rG

    Zash: except that most clients suck at rejoining.

  345. Ge0rG

    Zash: somebody could implement a server-side MUC bouncer that hides all of this from the client.

  346. Zash

    Ge0rG: *ahem* mod_minimix?

  347. Ge0rG

    Zash: I don't appreciate that name very much, but yes.

  348. Zash

    Naming things is hard

  349. Ge0rG

    Zash: also I had a brief look at the source code and decided not to load it on yax.im

  350. Zash

    Ge0rG: Sane choice.

  351. jonasw

    mod_minix -- run a minix inside lua and own all your traffic

  352. jonasw

    mod_mimimix -- complain about all attempts to join MIXes in the logs

  353. Ge0rG

    mod_mixtape - play low-quality music whenever somebody joins a mix

  354. Zash

    Hold on, how do you trick a MUC into subscribing to your presence?

  355. Ge0rG

    Oh. Hm.

  356. Ge0rG

    Right, adding a MUC to your roster doesn't imply much.

  357. Ge0rG

    I wonder what happens if you send a subscription request to a MUC

  358. Kev

    My concern is that things are bad with desyncs, and we'll make them worse by just stopping doing gc1.

  359. Kev

    And on a Draft XEP that's not on.

  360. Ge0rG

    Kev: we'll just make clear how bad it actually is.

  361. jonasw

    Kev, silently losing messages (what we currently have) is worse than explicitly dropping out of a MUC.

  362. Ge0rG

    Kev: but I'm open to suggestions how to transition into the new world of awesome MUC without causing regressions

  363. Kev

    jonasw: And that's not what's on the table.

  364. Maranda re-read the gdpr thing

  365. jonasw

    Kev, it’s not?

  366. Kev

    jonasw: What's on the table is silently losing some messages vs silently losing more messages.

  367. jonasw

    Kev, no, you don’t *silently* lose more mesasges

  368. jonasw

    the user and client are aware that they’re losing messages, which isn’t the case with a silent pseudo-resync which happens on accidental GC1.0

  369. Ge0rG

    are aware that they *were* losing messages,

  370. jonasw

    Ge0rG, true.

  371. Kev

    jonasw: But how many existing clients are dealing with whatever behaviour we're moving towards?

  372. Maranda

    So in the end "user must explicitly give consent to treatment of his/her data by 3rd parties (receiving) when using s2s" is legally covering glad we got to that at least.

  373. jonasw

    Kev, if the MUC replies with a "kicked" status code, every single one I think.

  374. Kev

    jonasw: I'm not opposed to fixings, but we do have to be sure we're actually fixing them.

  375. Ge0rG

    jonasw: I really dislike "kicked" as opposed to a presence-error

  376. Kev

    jonasw: Great, so the user isn't getting messages and eventually they might wonder why that tab has gone quiet and look why and see they left 3 days ago.

  377. Ge0rG

    jonasw: because a sane client won't auto-rejoin after being kicked

  378. Maranda oO(and "who would have told" ™️)

  379. jonasw

    Ge0rG, kicked + 333 maybe?

  380. Ge0rG

    jonasw: that's not backward compatible to clients not parsing 333.

  381. jonasw

    Ge0rG, I’m not sure if clients handle type="error"

  382. Ge0rG

    jonasw: I'm speaking of "sane" clients.

  383. jonasw

    Kev, dunno, I’d *expect* clients to tell me that I got kicked out of a MUC.

  384. jonasw

    Ge0rG, me too

  385. Anu

    so are we discussing MUC or what the new lighter MUC will be

  386. jonasw

    Ge0rG, have you made a survey how many handle type="error"?

  387. jonasw

    Anu, MUC

  388. Maranda

    Anu, uncertain.

  389. Ge0rG

    Kev: yes. It's better to see after three days that you got kicked than to lose three days worth of discussion and then silently rejoin

  390. Anu

    ah

  391. Kev

    Ge0rG: except probably you don't lose 3 days of messages under gc1, because you will have silently kinda rejoined.

  392. Ge0rG

    Anu: I've stirred some controversy on the standards@ ML

  393. Kev

    I'm not saying gc1 is a good thing.

  394. Kev

    Or arguing that it should stay.

  395. Ge0rG

    Kev: maybe you only rejoined after two days.

  396. Kev

    I'm just saying that it's not clear that we yet have a story for what happens next.

  397. Maranda

    And why auto-rejoining is insane?

  398. Maranda

    🤔

  399. Ge0rG

    Maranda: it isn't, unless you were just kicked

  400. Anu

    Group chat (as people expect it) is such a solved problem. In my honest opinion, we should probably spit up the IRC clone from the kind of group chat people use today (which is more of a distribution list)

  401. Ge0rG

    Anu: yes, but then everybody wanted their favorite feature in and we ended up with MIX

  402. Anu

    MIX?

  403. jonasw

    Anu, XEP-0396

  404. jonasw

    eh

  405. jonasw

    Anu, XEP-0369

  406. Ge0rG

    Anu: https://xmpp.org/extensions/xep-0369.html

  407. Ge0rG playing xep-bot

  408. jonasw

    good bot Ge0rG

  409. Kev

    It's MUC with the issues fixed.

  410. Ge0rG

    Kev: that's the optimistic view.

  411. Maranda

    -xep 369

  412. Bunneh

    Maranda: Mediated Information eXchange (MIX) (Standards Track, Experimental, 2018-03-18) See: https://xmpp.org/extensions/xep-0369.html

  413. Ge0rG

    I'm not convinced that MIX actually solves the problem we are talking about (s2s desync). All it provides is some hand-wavy "use MAM"

  414. Maranda

    -xep 396

  415. Bunneh

    Maranda: Jingle Encrypted Transports - OMEMO (Standards Track, Experimental, 2017-11-29) See: https://xmpp.org/extensions/xep-0396.html

  416. Kev

    Ge0rG: I think that's right, actually. We do need to get the MAM resync in there.

  417. Maranda

    :O

  418. jonasw

    yeah, MIX is in the state of "silent message loss", but with better recovery times than MUC

  419. Ge0rG

    jonasw: recovery times? I don't see no recovery times in MIX

  420. jonasw

    Ge0rG, in theory, each message stanza would trigger an s2sout attempt at the MIX side of things.

  421. Ge0rG

    Kev: so I assume your statement should read "MIX is MUC with additional issues." :P

  422. jonasw

    which is *probably* better than what happens with MUC-GC1.0-pseudo-resync which only happens when a client happens to update its presence.

  423. jonasw

    MIX fixes the resource part abuse.

  424. Kev

    And the long-term join.

  425. Maranda thinks currently MIX is in the "it'll cause a core meltdown", but he's vaguely biased.

  426. Kev

    And the multi-client.

  427. jonasw

    everybody loves core dumps

  428. Maranda

    Stick a state somewhere in that last sentence

  429. Ge0rG

    jonasw: I'm not sure this is a real problem. And if it is, I'm not sure that abusing the localpart of the MIX JID to contain two fields is a good solution.

  430. Ge0rG

    Kev: we can solve multi-client long-term join in MUC without touching a single line of XEP.

  431. Maranda

    Agreed

  432. Kev

    I'm quite sure that's not true.

  433. Ge0rG

    All we need is a bouncer on the user's account that syncs with 0048.

  434. jonasw

    Ge0rG, it doesn’t shake the concept of "same bare JID == same identity", which is good enough for me I think

  435. Ge0rG

    Or 0402, or whatever.

  436. Kev

    As long as we have full-JID sharing, iq is going to be broken.

  437. jonasw

    yeah

  438. Ge0rG

    jonasw: except in MIX you have a 1:N relationship between identities and JIDs over different MIXes

  439. Maranda

    Although I'm somehow also sure somehow "bncs" will also be a cause of nuclear meltdowns

  440. jonasw

    Ge0rG, I’m not sure that matters much.

  441. Ge0rG

    Kev: what are the IQ use cases in MUC?

  442. Kev

    Any time you want to do anything that involves an iq.

  443. jonasw

    Ge0rG, initiating a call with an occupant (not the whole MUC)

  444. Kev

    So the same as non-MUC.

  445. Ge0rG

    Kev: and self-references are self-references.

  446. Ge0rG

    The only IQs I'm actively using are (self)ping and version, and I just made a proposal to fix #1 and I can live with the ambiguity of #2

  447. Maranda eyes that "Thesis Survey" in jdev@

  448. Anu

    desync = netsplit ?

  449. Ge0rG

    Anu: kind of.

  450. Ge0rG

    Anu: https://mail.jabber.org/pipermail/standards/2017-October/033501.html has an in-depth explanation

  451. Maranda

    Ge0rG vcard:temp also

  452. jonasw

    Maranda, vcard:temp is on the account, not on the occupant

  453. jonasw

    Maranda, vcard:temp is on the account, not on the resource

  454. Maranda

    And time

  455. jonasw

    so that’s about the one case where it doesn’t matter in MUC :)

  456. Anu

    We should all just use EF net and be happy

  457. Maranda

    What? Hmm is there a difference jonasw?

  458. Ge0rG

    Maranda: yes, in MUC you query the full JID for the vcard, and it gets routed by the MUC to the account of the participant

  459. Kev

    jonasw: No, actually, vcard:temp is another example of iq being broken.

  460. Kev

    Because it should go to the full JID of the occupant, not to their bare JID.

  461. jonasw

    Kev, wha?

  462. jonasw

    ITYM the other way round?

  463. Kev

    So all* MUC implementations have some special casing to detect a vcard and send it to the wrong place (bare JID) instead of the normal routing rules [*probably].

  464. Ge0rG

    Kev: so there is a viable workaround for that.

  465. jonasw

    ah, "should" in the sense of "the normal routing rules"

  466. jonasw

    Ge0rG, so we wanna staple further workarounds onto MUC for every IQ which might ever need to go to the bare JID?

  467. Maranda is confused with occupant != account muc wise

  468. Maranda

    Waiting for cell to return ™️

  469. Ge0rG

    jonasw: I'm sure the incremental overhead is minuscule.

  470. jonasw

    Ge0rG, but the adoption delay?

  471. jonasw

    and the difficulties for new implementers.

  472. jonasw

    and of course, the client code which needs to special-case requesting stuff from MUC occupants.

  473. Ge0rG

    jonasw: write it down in 0045.

  474. jonasw

    you mean like the vcard:temp hack is written down?

  475. Ge0rG

    jonasw: the special-casing in my client is just in two places :>

  476. Ge0rG

    jonasw: dunno. I'm not a server author. I'm busy enough keeping 0045 usable for client devs.

  477. Maranda

    Well iq routing has always been hassle in muc, e.g. who do you send to on ping, version, time etc

  478. Ge0rG

    a.k.a. not my department.

  479. Maranda

    In case of shared nick

  480. Maranda

    😎

  481. Ge0rG

    Maranda: I suggest "highest priority"

  482. Kev

    Maranda: Yes, that's one of the things that's fundamentally broken with MUC addressing.

  483. Ge0rG

    no, "most available"

  484. jonasw

    I suggest least mobile

  485. Maranda

    Least mobile 🤔😆

  486. Maranda

    And no hacks aren't written down e.g. Multi resource nicks

  487. Ge0rG

    Maranda: PR the XEP!

  488. Maranda

    Ge0rG I would use someone more literate than myself english wise

  489. Maranda

    😜

  490. Ge0rG

    Maranda: just don't plaster it with Emoji :P

  491. Holger

    #18.1.2 Ghost Users 👻

  492. Holger

    #5 Roles, Affiliations, and Privileges 😱

  493. Maranda

    Mobile Chrome even hangs browsing xeps

  494. Maranda

    🤔

  495. Ge0rG

    I was going to suggest status code 666 for the Ghost Rider.

  496. Ge0rG

    Or maybe the GOST Rider. zinid and Andrew would appreciate that.

  497. Maranda

    666 which in reality is 999

  498. edhelas propose to ping Ge0rG to check the state of all the MUCs

  499. Ge0rG

    edhelas: great idea. And then I quit XMPP and everybody's clients go offline

  500. edhelas

    then I'm adding "Ge0rG MUST stay online" to the XEP

  501. Ge0rG

    edhelas: I'm not sure you need to write that into the XEP, it might suffice to get a Council vote.

  502. Ge0rG

    I'll request XSF funding for a multi-homed redundant-hardware HA cluster to run my poezio.

  503. Ge0rG

    Oh, wait. poezio needs restarts as well. I will request funding to develop a new client written in Erlang.

  504. jonasw

    Maranda, regarding english literacy, that’s the editors job when in doubt

  505. Maranda

    😲

  506. Ge0rG

    jonasw: I didn't want to say that, knowing that the editors are pretty busy

  507. jonasw

    Ge0rG, that’s no reason not to say the truth :)

  508. Ge0rG

    jonasw: while you are there... I have some pending PRs :D

  509. jonasw

    Ge0rG, I know that

  510. jonasw

    I have a pending PR mysefl

  511. jonasw

    but unfortunately, what you were saying is also true ("the editors are pretty busy")