XSF Discussion - 2018-04-20

  1. ralphm

    Hmm, just noticed that Conversations doesn't (also) send XEP-0080 payload when sharing location.

  2. daniel

    ralphm: is there any client that will do something reasonable if I just stick a geoloc element in the message (w/o the pubsub overhead)?

  3. daniel

    Assuming that this is what you are talking about

  4. ralphm

    I'm not sure, to be honest, but it is something I'm suggesting being implemented in what we are doing.

  5. lovetox

    are these not 2 different use cases

  6. lovetox

    i always thought xep 80 is more of a, contantly sharing your location all the time

  7. lovetox

    conversations just shares the location at one point in time with a geo uri or not?

  8. jonasw

    mmm, I know of a protocol which suggested inclusion of XEP-0080 payload into messages. Ge0rG?

  9. jonasw

    (it’ll haunt you forever!)

  10. lovetox

    either way gajim supports xep 80 🙂

  11. MattJ

    lovetox, the XEP provides two parts: the data format (<geoloc>), and a recommended transport (PEP)

  12. MattJ

    The point is, any time you need to encode location in XMPP, the same data format/code can be reused without inventing something new

  13. lovetox

    ah i see

  14. lovetox

    so you want to use the geoloc element with another transport

  15. jonasw

    extensible XML is extensible

  16. lovetox

    in this case a message

  17. MattJ

    So yeah, if you want to send a specific location once over XMPP, but don't want to publish it to all your contacts, I think including it directly in a message is quite sensible

  18. Zash

    So, the thing, it's just sending <body>geo:x,y</body> right?

  19. lovetox

    yeah and this is useable by the user even if the client doesnt support locations

  20. lovetox

    i think firefox even supports this uri scheme

  21. Zash

    geo:0,0

  22. Ge0rG

    jonasw: no!

  23. Ge0rG

    jonasw: or I'll PR xmpp-echo-bot into xmpp.org/clients!

  24. MattJ

    Right, so like OOB (which is similar - it defines a data format as well as different ways of using it, iq vs. message), the <body> may be used only as a fallback

  25. Zash

    Having a graceful fallback in <body> is sane.

  26. Zash

    Having *only* the body is meh.

  27. MattJ

    However like OOB, we have the problem where it's not known if the <body> is just a fallback, or also includes some information to which the data payload is an addition

  28. MattJ

    e.g. <body>Don't come to this place, here be dragons</body><geoloc>...</geoloc>

  29. MattJ

    Client sees <geoloc> and says "I know this! They sent a location, so I'll show that instead of the <body>..."

  30. Zash

    There used to be thing magical awesome feature negotiation, but we've killed that, thanks to Carbons and MAM

  31. MattJ

    Zash, that never worked with offline messages either

  32. lovetox

    MattJ we can decide

  33. lovetox

    the dataformat has a description attr

  34. MattJ

    Right, that's currently a problem I have with OOB

  35. lovetox

    so if we have description ignore body

  36. MattJ

    That means I can't use OOB like an "attachment" feature

  37. MattJ

    <body>Here is that Word document containing the virus I received earlier</body><oob><desc>Word document</desc>...</oob>

  38. daniel

    Fwiw Conversations will only use the oob tag if it's either the same as the body or if the body doesn't exists

  39. MattJ

    I can think of a protcol solution, not sure whether it's actually a good idea or not

  40. daniel

    I'm not defending oob as the best thing ever invented

  41. MattJ

    <hide-body-if-you-understand>jabber:x:oob</hide-body-if-you-understand>

  42. daniel

    But the word document situation wouldn't happen

  43. Zash

    > Here is that Word document containing the virus I received earlier Where, I don't see it?

  44. MattJ

    Zash, fair point :)

  45. Zash

    Nice things be unavailable.

  46. MattJ

    So for backward compatibility, we have to always use <body> as a fallback

  47. MattJ

    so <desc> suddenly makes sense as a non-fallback piece of text

  48. lovetox

    yes if desc is there hide body

  49. Zash

    If only anyone actually used taht

  50. Zash

    I'd wanna have this, but it won't work today: body := $desc \n $uri oob := { uri = $uri, desc = $desc }

  51. MattJ

    Zash, yes, pretty much what I'm proposing

  52. MattJ

    The current Conversations logic makes sense, to defend against any clients which may be treating <body> *not* as a fallback

  53. MattJ

    But I'm not sure whether any clients actually do that today

  54. MattJ

    So we just need to document that oob always overrides body, and the accompanying text, if any, is in <desc>

  55. daniel

    > I'd wanna have this, but it won't work today: > body := $desc \n $uri > oob := { uri = $uri, desc = $desc } I can live with that.

  56. daniel

    For now it won't break Conversations.

  57. daniel

    And in the future I might implement support

  58. MattJ

    daniel, iirc you said the text wouldn't be displayed in any case?

  59. MattJ

    Oh right, it would ignore the oob for now

  60. daniel

    Well by not break I mean Conversations would display the fallback

  61. MattJ

    Got it

  62. Ge0rG

    it would break inline image display ;)

  63. MattJ

    Luckily XEP-0066 is still Draft :)

  64. Kev

    Does 66 have anything over SIMS?

  65. MattJ

    But even the example there is using it in an attachment-style

  66. MattJ

    Kev, yes, things support it already :)

  67. Zash

    Small, simple, self-contained.

  68. MattJ

    I think it's simple because it's always just a URL

  69. MattJ

    SIMS suddenly pulls in Jingle

  70. MattJ

    and that's quite a commitment for a client that simply wants to display an image

  71. Kev

    SIMS doesn't need to be Jingle though, does it? It can just do URLs?

  72. Kev

    Or I've completely misunderstood.

  73. Zash

    But why would you if you're just sending URLs anyways?

  74. Zash

    (SIMS has more things that are useful tho)

  75. Kev

    Because you usually want metadata with it.

  76. MattJ

    Kev, "a client supporting this XEP MUST implement Jingle File Transfer (XEP-0234) [2] and HTTP File Upload (XEP-0363) [4]."

  77. MattJ

    which is weird, because even to just receive and display images from others, I MUST implement a XEP related to uploading?

  78. Kev

    Yeah, either it's useful just for fetching stuff, in which case it shouldn't have that, or we should move all the metadata stuff into references itself.

  79. Zash

    Maybe separate requirements for sending and receiving?

  80. MattJ

    and rather than forcing client to implement Jingle, there should be a fallback as we have with the OOB solution

  81. MattJ

    So I think that answers why OOB > SIMS right now (but may not always be)

  82. Ge0rG

    all the refererence / link XEPs suck in different ways.

  83. MattJ

    The sad truth is, anybody can click a URL, but you can't count on all of a user's clients supporting Jingle

  84. Kev

    Are you interested in just a clickable URL though?

  85. MattJ

    (I don't think any of mine do, and one is a console client that I use via ssh... what is it supposed to do with a Jingle reference?)

  86. MattJ

    No, I'm saying that a clickable URL is the common fallback that works absolutely everywhere

  87. lovetox

    xep 80 links to a invalid site

  88. lovetox

    https://xmpp.org/extensions/gps_datum.html

  89. Andrew Nenakhov

    > Luckily XEP-0066 is still Draft :) Btw I don't see why would anyone use 066 over 221 for inline image display

  90. MattJ

    Heh

  91. daniel

    by the way if any server operators are interested in having their uptime tracked you can add your own server with this form: https://status.conversations.im/add/

  92. daniel

    you can of course also just self host the thing. but apparantly some people don't want to

  93. jonasw

    GDPR meeting in 5? pep., Ge0rG, winfried

  94. pep.

    oh right

  95. Ge0rG

    🤦

  96. winfried

    Give me one minute

  97. jonasw

    Ge0rG, why?

  98. Zash

    > 15:56:00 jonasw> GDPR meeting in 5? You have until 16:01

  99. Ge0rG

    jonasw: it was just an ACK of my presence

  100. jonasw

    weird way to ack

  101. pep.

    !

  102. pep.

    I got beverage and snack, all the good stuff

  103. Ge0rG

    🙋

  104. Maranda

    Ge0rG's famous ack

  105. Ge0rG

    better now?

  106. Maranda

    Well I imagine a headdesk would be stranger for a ACK

  107. jonasw

    Ge0rG, yes

  108. winfried acks his presence

  109. pep.

    !

  110. Ge0rG

    Are we there yet?

  111. jonasw

    .

  112. winfried

    all present

  113. winfried *bangs* the gavel

  114. winfried

    pep.: thanks for your logs!

  115. pep.

    I was a bit lost with the two last meetings, not sure in what category to put what we talked about

  116. winfried

    we have to do the spamdetection and can then move on to the consequences

  117. jonasw

    I’d like to insert a point: do we want to send a posting to the gdpr list set up by the debian folks?

  118. winfried

    pep.: When I have a bit time to spare, I wil check

  119. pep.

    yes I would like to

  120. Ge0rG

    jonasw: 👍

  121. pep.

    jonasw, can do

  122. winfried

    good plan

  123. Ge0rG

    tiden up the wiki a bit after this meeting and send it out?

  124. pep.

    Ok

  125. winfried

    that is that earth.li list?

  126. winfried

    Ge0rG: good plan, maybe add a summary so far?

  127. pep.

    yes

  128. pep.

    winfried, boarf

  129. winfried

    LOL

  130. pep.

    It's still a wip

  131. winfried

    it is

  132. winfried

    do we need any reflection on the process before diving into it?

  133. winfried

    I guess not... ;-)

  134. winfried

    last point of 1.1d before diving into 1.1e: spam detection. What are we doing there and is that justified

  135. pep.

    If we want to provide a proper service to other users of the network I guess we have to yes

  136. Ge0rG

    winfried: what I am doing: automatic analysis of all messages for matching one of two sets of certain (super secret) criteria.

  137. winfried

    pep.: I was referring to legal grounds for processing, but you are right, that doesn't justify it

  138. Ge0rG

    messages that match criterion 1: manual analysis of body text (this might be really evil, dunno)

  139. Ge0rG

    messages that match criterion 2: automatic blocking of the sender JID forever.

  140. pep.

    hmm, wouldn't any manual analysis directly fall under 9.1?

  141. winfried

    Ge0rG: fixed criteria or self-learning/statistical ones?

  142. jonasw

    Ge0rG, all of that falls apart once spammers start to OMEMO things, right?

  143. jonasw

    or at least the body text analysis

  144. Ge0rG

    winfried: fixed criteria. The manual analysis is only used to improve the criteria-2 list

  145. pep.

    Ah, you're talking about non-bayes analysis or similar I guess

  146. Ge0rG

    jonasw: yes. I'm eagerly awaiting that day so I can start blocking OMEMO

  147. winfried has a head crunching regulations and articles

  148. Ge0rG

    *crunch*

  149. pep.

    hmm, the e2ee thing seems annoying yeah

  150. winfried

    pep.: e2ee is a security risk!

  151. pep.

    :)

  152. pep.

    Ge0rG, I'd say that's a bit involved for spammers no?

  153. jonasw

    manually reading the body seems fairly evil though

  154. pep.

    Anyway..

  155. winfried

    lets brainstorm a bit

  156. pep.

    jonasw, agreed

  157. moparisthebest

    it's ok, the spammers aren't going to sue him for it

  158. winfried

    abuse detection/prevention is a ground for processing

  159. pep.

    moparisthebest, might not be spammers he's reading messages of

  160. daniel

    I think the target audience of their spam hates omemo and uses pidgin or other crappy messengers. So I honestly wouldn't expect them to start using omemo any time soon

  161. jonasw

    winfried, in any case: spam filtering is currently not standardised and I’m not sure if we need to cover it within the XSF

  162. winfried

    as long as it proportionate

  163. jonasw

    at least not at this point in time

  164. winfried

    so reading every message is not proportionate, reading messages already marked as spam is

  165. pep.

    winfried, is it?

  166. pep.

    is it written in your bible

  167. jonasw

    winfried, depends on how you mark as spam

  168. moparisthebest

    point is, no one could tell if you did or not, so it's legal!

  169. pep.

    moparisthebest, shush

  170. jonasw

    if you learn on spam based on viagra and penis enlargement, your spam detection could easily trip off at 9.1-relveant non-spam content.

  171. moparisthebest

    what this: Ge0rG, do you ever manually read messages? (answer no)

  172. winfried

    pep.: well, that is one of the things I was doubting about

  173. winfried

    but here in the netherlands 'escalating fraud prevention' is accepted right now

  174. pep.

    jonasw, your spam filter could also be "true"

  175. winfried

    (though a bit controversial)

  176. winfried

    pep., jonasw very true

  177. jonasw

    I motion that we skip spam detection of any kind for now, because of lack of standardisation. Just leave a note that any type of body analysis might go into 9.1 realm.

  178. winfried

    in the escalating things, metadata is the first step, then automated detection then manual analysis

  179. Ge0rG

    moparisthebest: yes I do.

  180. winfried

    moparisthebest: it is justifyable if it is proportionate and if it can't be done in an other way

  181. moparisthebest

    oops, you messed up Ge0rG :P

  182. winfried

    jonasw: I think we need to give some warnings about it, but we can't fully handle it indeed

  183. winfried

    so +1 to the motion of jonasw

  184. pep.

    how the hell does google justify that

  185. pep.

    yeah I also want to leave this aside for now

  186. winfried

    pep.: Google just lets you sign that they own your soul and your communications

  187. winfried

    Ge0rG: ?

  188. winfried

    is it me, or did everybody leave for a friday afternoon beer on a terrace?

  189. Zash

    Good idea!

  190. pep.

    I was also planning something similar

  191. pep.

    it's sunny in the England, joy! ✎

  192. pep.

    it's sunny in England, joy! ✏

  193. Ge0rG

    winfried: what was your question, sorry?

  194. Zash

    It was sunny here yesterday.

  195. Zash

    Now it's grey meh.

  196. moparisthebest

    kinda on topic: https://politics.stackexchange.com/questions/30509/how-are-gdpr-fines-actually-enforced-for-us-companies-with-no-physical-presence

  197. winfried

    do you ack leaving spam detection with a note about possible problems with it?

  198. moparisthebest

    "The GDPR requires non-EU entities handling EU data to appoint a representative in the EU, and this representative will be able receive the fines or other penalties relating to regulation compliance." ;; haha EU lawmakers really are insane aren't they?

  199. Ge0rG

    winfried: yes, ack

  200. winfried

    Q1.1e!

  201. pep.

    winfried, what do you want to put in 1.1e?

  202. Ge0rG

    pep.: I'd say specific action items for people involved (i.e. server operators)

  203. pep.

    State what fine if you don't do x or y?

  204. winfried

    up to now we found several limits, things to consider regarding the processing we are doing

  205. pep.

    istr winfried also talking about drafting a policy or sth

  206. Ge0rG

    pep.: the fines aren't clear yet. The maximum fines are well-defined, but there are zero rulings yet

  207. winfried

    I think we should no look at what we must do to fix those issues

  208. Ge0rG

    winfried: {not,now}?

  209. winfried

    like s2s to a server that is violating privacy

  210. winfried

    now

  211. pep.

    winfried, I guess you can blacklist once you become aware

  212. Ge0rG

    but how do you become aware?

  213. winfried

    shall we first make a list of issues to consider?

  214. Ge0rG

    I don't think it's useful in any way to block s2s

  215. pep.

    Ge0rG, that'S the trick

  216. Ge0rG

    We need to ensure that the users are informed about the possibility of their data leaving the EU

  217. winfried

    OK, I opened pandora's box of s2s

  218. winfried

    lets empty it...

  219. winfried

    issue a: can it be justified?

  220. winfried

    (to do s2s)

  221. pep.

    what can?

  222. pep.

    ah, we said article 6 and 49.1b

  223. pep.

    6.1b and 49.1b ?

  224. winfried

    pep.: exactly, but that assumes no more processing then is needed for the task

  225. pep.

    We can also ask for consent with 6.1a and 49.1a iirc

  226. winfried

    so how do we assure there is no more processing then needed for the task?

  227. pep.

    For the part that's not covered by implicit consent

  228. winfried

    pep.: yes

  229. winfried

    but how do we know we need extra consent?

  230. pep.

    all we haven't covered in 1.1c/d I would say?

  231. winfried

    I guess we can't enforce this by technical means, it is a legal issue

  232. moparisthebest

    does an incoming message to your user make it your user's message? in which case you already have their consent?

  233. winfried

    moparisthebest: no

  234. moparisthebest

    why not?

  235. pep.

    winfried, did we not say yes to this question?

  236. winfried

    moparisthebest: it still contains pii from the sender

  237. pep.

    right, assuming no further analysis of the message

  238. moparisthebest

    that they willingly sent to your user, put completely under your user's control?

  239. moparisthebest

    which they granted consent to you for, maybe?

  240. winfried

    pep.: on storage (MAM) of the conversation not on the processing (relaying) the message

  241. winfried

    moparisthebest: by willingly sending it to a user, the sender agrees to the processing of sending the message, the receiver is no part of that

  242. moparisthebest

    does anyone actually know that are is everyone just guessing until it's tested in court?

  243. pep.

    hmm

  244. MattJ

    moparisthebest, nobody knows

  245. winfried

    moparisthebest: there are some wp29 guidelines, they have a legal status

  246. moparisthebest

    I'd think they'd all be equally arguable in court

  247. jonasw

    winfried, didn’t we establish last time the opposite of that?

  248. jonasw

    like, received message == recipients content => covered by recipients consent.

  249. winfried

    jonasw: hmmm... refresh my mind (it has a friday explosion)

  250. moparisthebest

    again, what are the email providers doing? that's really all we need to know, numerous email providers are far bigger and have far more money than the entire XMPP network

  251. jonasw

    winfried, I’m semi-afk myself, but I think we figured that due to the fact that the recipients server has consent from the recipient for processing, it’s fine because the sender gave the recipient the data.

  252. jonasw

    moparisthebest, nobody knows!

  253. winfried

    jonasw: I thought that was only in the context of MAM at the receiver server

  254. jonasw

    moparisthebest, they won’t tell you because it threatens them legally

  255. pep.

    moparisthebest, https://www.earth.li/pipermail/gdpr-discuss/2018-April/000013.html a quite I liked in there, "Of course, anyone's reading might contrast quite a bit from how lawyers will over time engineer courts into interpreting it"

  256. jonasw

    winfried, okay, what are we talking about if not about MAM?

  257. moparisthebest

    jonasw, than that's what we should find out rather than trying to make up stuff on our own?

  258. winfried

    jonasw: relaying the message, logging it, spam filtering it

  259. jonasw

    moparisthebest, except that they won’t tell us

  260. winfried

    using it for profiling for targeted advertisement

  261. jonasw

    because it threatens them legally to do so, I guess

  262. pep.

    moparisthebest, also business opportunities, so insentive not to reveal how they do it

  263. jonasw

    that, too

  264. jonasw

    but I guess they’re more afraid of them actually not being compliant

  265. pep.

    possibly

  266. moparisthebest

    but there are plenty of more open ones that would too?

  267. moparisthebest

    presumably

  268. winfried

    moparisthebest: there are many things unclear on the gdpr, but many thing things *are*, we can anticipate on that

  269. jonasw

    hm, we could ask posteo

  270. winfried

    moparisthebest: and many companies try to ignore the obvious, for example because it doesn't fit in their business model

  271. moparisthebest

    it's not great but, seems like good odds an email provider will be targetted way before any xmpp provider, could just wait and see...

  272. pep.

    moparisthebest, not sure that's a good option

  273. moparisthebest

    the other option is for non-lawyers to try to interpret lawyer-speak, and guess what a lawyer and judge will decide

  274. pep.

    So.. we didn't get really far today

  275. moparisthebest

    also, not a good option

  276. winfried

    moparisthebest: I don't want to tell my customers "we are neatly ignoring the law, because we hope somebody else gets caught first"

  277. moparisthebest

    whether you try really hard to comply or not, that's still essentially the position you are in

  278. winfried

    pep.: yes, I am a bit frustrated too...

  279. pep.

    moparisthebest, if this doesn't interest you, fine

  280. winfried

    moparisthebest: it is not that black-white, many things *are* clear

  281. jonasw

    sorry, I was more distracted than I expected during this timeslot :/

  282. moparisthebest

    don't get me wrong you guys are doing good work and finding the baseline of generally what looks to be compliant

  283. moparisthebest

    but none of you are lawyers, and even if you were, they can be wrong too

  284. moparisthebest

    it's a terrible situation, I'm just glad I'm not in the EU

  285. pep.

    moparisthebest, yes everybody can be wrong and we'll see on the first court cases

  286. pep.

    In the meantime, we kind of have to do something about it anyway

  287. Holger

    That's true for basically any law that applies to whatever you do.

  288. pep.

    yes

  289. Ge0rG

    moparisthebest: the good thing is that if you show to the court that you clearly did your best to follow the rules, your probability of ending up in jail sinks

  290. MattJ

    Obligatory link to http://ansuz.sooke.bc.ca/entry/23 if you haven't read it, on the subject of law and computing

  291. moparisthebest

    my only concern pep. is you overanalyze something and end up crippling federation or something that is useful

  292. pep.

    moparisthebest, we're only giving guidelines, and we welcome anybody to give input, or even bring lawyers to the dicussion if possible

  293. pep.

    moparisthebest, also as Ge0rG said

  294. moparisthebest

    yea but if the guidelines end up being 'disable federation except on an opt-in manual basis' that ruins everything

  295. SamWhited

    FYI, there's a bit of XMPP discussion in this Google Allo/SMS thread: https://news.ycombinator.com/item?id=16882539

  296. winfried

    moparisthebest: I think we are in matter of fact analyzing how far we can go with federation without running into big problems

  297. pep.

    that is not where we're headed no

  298. pep.

    Shall we plan next

  299. winfried

    yes... I will try to make a analysis/summary of the discussion so far and the issues to tackle before it

  300. pep.

    I can't do Wed and (Fri morning)

  301. pep.

    Tue 12:30 CEST as before?

  302. jonasw

    pep., that would work for me

  303. winfried

    Tue I am stuck

  304. pep.

    winfried, yes that'd be nice to know where we're at

  305. pep.

    Mon maybe?

  306. winfried

    mon wfm

  307. pep.

    Mon 1230 CEST

  308. winfried

    wfm

  309. pep.

    jonasw, Ge0rG

  310. jonasw

    pep., can do

  311. Ge0rG

    Mon and Tue should both work

  312. pep.

    Ok!

  313. pep.

    Mon 1230 CEST it is

  314. pep.

    *bang*

  315. Ge0rG

    pep.: thanks for chairing! ;)

  316. pep.

    haha

  317. Ge0rG

    thanks to winfried too, obviously

  318. Ge0rG

    Sorry I was semi-AFK, had two important and unscheduled customer calls :(

  319. winfried is searching the gavel

  320. winfried

    Ge0rG: I noticed something like that already, can happen

  321. jonasw

    thanks all

  322. pep.

    https://news.ycombinator.com/item?id=16882862 "an entirely over-the-top service that everyone could use, on any platform, without the consent, extra billing or buggy implementation of their carrier.", I guess they're missing the point, you still get the consent (in their meaning of the word) of WhatsApp to send your messages.

  323. moparisthebest

    https://www.smbc-comics.com/comic/help ha lawyers eyeing GDPR stuff

  324. lovetox

    The Last Call ends on 2017-12-12

  325. lovetox

    says xep 363

  326. lovetox

    so 4 months later what happens now?

  327. MattJ

    I last see an email from Dave Cridland saying: "Re-reading this and other feedback, I'm going to push back on moving this to Draft until substantial improvements are done to Security Considerations in particular, and normative language use in general."

  328. MattJ

    There has been an update to the XEP since then however

  329. SamWhited

    It might be time for the editors to reissue the LC on that

  330. daniel

    I'll do one tiny update. Give me second

  331. lovetox

    does the xsf have tool to track these things?

  332. lovetox

    there are probably 100 xeps in different states that have deadlines

  333. lovetox

    my observation is that these dates are not actually tracked, so the deadlines mean nothing

  334. lovetox

    i dont know what the correct process is, but a xep where the LC ended and it was voted to not advance, should be moved back to experimental or something

  335. jonasw

    lovetox, seems legit

  336. jonasw

    editor’s bsy though

  337. lovetox

    and not kept in this LC ended, but we have to search the mailinglist what actually happend -state

  338. Kev

    As with all things, feel free to help do something about it :)

  339. lovetox

    i just did, its not meant as whining, i deal with this at work everyday, i asked if you have a tool to track these deadlines?

  340. Kev

    Not beyond basic things like popping it in Trello (unless jonasw tells me we've got something better I'm not aware of).

  341. Kev

    We could, in principle, scrape the dates out of the XEPs automatically, but I don't believe we have anything currently to do that.

  342. Zash

    `grep`

  343. lovetox

    is there any automatic state changes happening?

  344. lovetox

    like triggered by something, and executed by the server without the editor doing something?

  345. lovetox

    or does every state change need a manual triggering by the editor?

  346. Kev

    State changes are all manual (which is right, I think).

  347. Kev

    Sending emails is also manual, which isn't right - that bit's nearly automated but not quite finished.

  348. lovetox

    so if every state change is manual, then a simple excel (or whatever you use on linux) list with the 400 xeps and there current status would be sufficient

  349. lovetox

    if its on the server and everyone has access to

  350. lovetox

    before council meeting, look at the list, filter state X look at deadline, and bring to vote

  351. lovetox

    its not really elaborate solution, but i think thats sufficient for the task

  352. MattJ

    I don't think the spreadsheet part is even necessary

  353. Kev

    I don't think that helps in this particular case, though, which was that it was blocked pending changes, and either the changes didn't happen, or it wasn't clear that they had.

  354. lovetox

    the problem is, nobody looked if they happend

  355. lovetox

    because it was not on the agenda anymore

  356. lovetox

    which it would have been if there was a list with all LC xeps

  357. lovetox

    because then it would be easy to look at all LC every council meeting

  358. lovetox

    and im not sure what you mean by "blocked"

  359. lovetox

    if LC ended, and you block it, then it cant be in LC anymore

  360. lovetox

    or maybe thats the problem, that its not usual to set the xep back to experimantal

  361. MattJ

    I feel almost like we need some tests for the xeps repo to highlight inconsistencies

  362. Zash

    `xeps$ xpath -e /xep/header/lastcall xep-0???.xml`

  363. Kev

    lovetox: Because it shouldn't go back to Experimental really. According to our process it should be rejected.

  364. Kev

    Which is obviously not right.

  365. Kev

    So just leaving it in Proposed is what tends to happen.

  366. lovetox

    your process gives you only Accepted or Rejected

  367. lovetox

    ?

  368. lovetox

    after a LC

  369. lovetox

    this seems not good, maybe add that it can be set back to experimental if the xep in gerneral is useful, but lacks some things

  370. Dave Cridland

    Yeah, we should allow popping things back to Experimental.

  371. Dave Cridland

    Although possibly the right thing to do is pop them into Rejected, but allow Rejected XEPs to be pulled back to Experimental, like Deferred ones.

  372. Dave Cridland

    (The difference being that if Council has rejected it, and nobody does anythign further, it should probably stay rejected and not automatically go back to Experimental)

  373. Ge0rG

    Dave Cridland: that sounds like the perfect recipe for offending authors.

  374. Kev

    I'm not sure that's true (Dave)

  375. Kev

    It seems that an abandoned LC XEP is much like an abandoned Experimental XEP.

  376. Dave Cridland

    Kev, So Deferred?

  377. Kev

    And letting them both be Experimental at the time of last action, and defer naturally seems sane to me.

  378. ralphm

    Are we talking about the Proposed state?

  379. Ge0rG

    Deferred sounds better

  380. Kev

    ralphm: Yes.

  381. lovetox

    you dont want to set it to a state where devs are scared to implement it, only because one council member thought some minor thing has to be adjusted

  382. Kev

    So an E with 5 months before Def goes to LC, gets -1, it then goes back to E for another 5 until it goes Def.

  383. lovetox

    so Rejected sounds bad

  384. Kev

    Or something.

  385. Kev

    lovetox: Indeed.

  386. lovetox

    Yes Kev your proposal sounds sane

  387. ralphm

    Rejected would be the appropriate state if the author is unwilling to change it based on said council members' comments.

  388. Kev

    ralphm: I don't think so based purely on that criterion.

  389. ralphm

    I am ok with an edge Rejected->Experimental

  390. lovetox

    yes of course, the case we talk currently is, nobody had time to look at things, or forgot but the xep is a good xep 🙂

  391. Kev

    Because if it's a worthwhile XEP with an intransigent author, the right thing is to assign a new author.

  392. Kev

    Not to kill the XEP.

  393. ralphm

    Kev: allowing Rejected->Experimental would enable just that, no?

  394. Kev

    ralphm: Pointlessly, IMHO.

  395. lovetox

    Rejected should be an end state

  396. lovetox

    in my opinion

  397. Kev

    I think allowing LC to end in any of Draft, Rejected, Experimental would be good to me.

  398. ralphm

    Somebody wants to pick up the Rejected XEP, does the work, suggests going back to Experimental.

  399. Kev

    And leaving it to Council to decide which.

  400. ralphm

    Sure

  401. lovetox

    so in this case now with httpupload

  402. ralphm

    But then you have to define how a vote in Council causes which transition

  403. lovetox

    i message the editor, saying LC has ended, no changes on the xep

  404. lovetox

    then he has to set it to rejected

  405. lovetox

    10 minutes later daniel messages: oh i make the change i forgot

  406. lovetox

    then he has to put it again into experimental..

  407. ralphm

    lovetox: in the current process, only Council can make it go to Rejected to begin with, after a vote.

  408. lovetox

    good, so council should decide

  409. ralphm

    So it is Experimental -> Proposed -[vote]-> Rejected/Draft

  410. lovetox

    experimental because author was reached and promises to do something

  411. lovetox

    or rejected, we cant reach anyone

  412. lovetox

    i feel there is no need for a hard state machine, LC -> Rejected -> experimental

  413. lovetox

    although i dont care in the end, but this probably generates work for the editor

  414. lovetox

    and has no real gain

  415. lovetox

    council can determine if its worth to go from LC -> Experimantal

  416. ralphm

    If a modification to XEP-0001 is proposed, including how voting in Council works with three possible outcomes, I'd of course be happy to entertain that proposal in an upcoming Board meeting/

  417. MattJ

    I'm not sure LC should be an explicit state, I think that's the problem here

  418. Dave Cridland

    lovetox, The benefit of a hard state machine is that people are slightly less likely to scream about abuse of power.

  419. Ge0rG

    It's great to have a process to change the process.

  420. Kev

    MattJ: That may well be.

  421. lovetox

    Dave Cridland, hm yes didnt saw it from this point of vie

  422. Ge0rG

    Dave Cridland: I'm pretty sure if there is a Collusion of Council, we can figure out a way to formally follow the process to achieve any desired abuse of power.

  423. Ge0rG &

  424. lovetox

    also would it be a abuse of power if the council votes on the state?

  425. lovetox

    i think not

  426. Kev

    If I was proposing wording to xep1, I would go with a slightly more formal: When LC expires, Council shall vote on advancement to Draft. If this vote fails Council shall then vote on Rejection. If this vote also fails, the XEP shall return to a state of Experimental (and shall later be deferred after the normal period after the substantive modification).

  427. ralphm

    I'd +1 that

  428. ralphm

    So please send a request to that end to Board

  429. ralphm

    I think it would be useful, though, to actually record objections in the Changelog. We haven't done this, before, but it might be useful to see the history if progressing failed at some point.

  430. Ge0rG

    +1 to that

  431. Maranda 💕 muc favicons.

  432. Maranda

    🤣

  433. ralphm

    https://twitter.com/ralphm/status/987382007452889088?s=09

  434. ralphm

    RCS? Come on.

  435. Maranda

    Apparently

  436. moparisthebest

    difference being they couldn't charge xmpp servers for federation like they can with carriers I'm assuming

  437. moparisthebest

    what is this? google's 10th attempt at instant messaging? 20th? I've lost count

  438. lovetox

    and this one is obviously going to failk ✎

  439. lovetox

    and this one is obviously going to fail ✏

  440. moparisthebest

    sure I mean why would anyone think the 20th time is the charm :)

  441. ralphm

    moparisthebest I'm not sure if that's true, but it has little to do with Open

  442. moparisthebest

    right it's not open at all, this RCS business

  443. Zash

    Which RCS is this even?

  444. moparisthebest

    Zash, https://techcrunch.com/2018/04/19/google-changes-its-messaging-strategy-again-goodbye-to-allo-double-down-on-rcs/

  445. Zash

    https://en.wikipedia.org/wiki/Rich_Communication_Services ?

  446. MattJ

    Yes

  447. Ge0rG

    RCS is the massive fail that happens when telcos try to grasp and monetize whatsapp

  448. lovetox

    i dont get it, its not anymore just about messaging

  449. lovetox

    this reads like all it does is send one message to a contact

  450. moparisthebest

    we should make bets how long this lasts before google abandons it

  451. lovetox

    i bet it doesnt even start

  452. Ge0rG

    "RCS could allow free chats across different networks on Android or other devices" except that it's operated by the telcos and billed by the message

  453. moparisthebest

    I give it maybe a year before they give up

  454. moparisthebest

    yea I agree lovetox I don't think it'll ever get off the ground, but I give it a year until they give up

  455. moparisthebest

    think of the poor telcos missing out on all those sweet per message fees! <- something no one has ever said except telco CEOs

  456. Ge0rG

    RCS was "introduced" in 2012 and nobody wanted it but the carriers. No idea who paid Google how much to get them behind it.

  457. Ge0rG

    But as it doesn't even fit Google's business strategy, I would counter-bet that this public announcement is all we are going to see of their involvment

  458. lovetox

    in most countrys sms are free anyway

  459. Ge0rG

    Okay, there is _maybe_ one way for Google to align it with their strategy - by selling targeted RCS spam to companies

  460. Ge0rG

    lovetox: SMS were free, then telcos discovered they can bill users per message and then it took over a decade to get decent flatrate offers

  461. lovetox

    yeah i just mean, now why going back

  462. Ge0rG

    I've only switched to an SMS flat two months ago

  463. lovetox

    nobody will accept paying for a message

  464. Ge0rG

    lovetox: because RCS is a premium service

  465. Ge0rG

    lovetox: have a look at MMS.

  466. lovetox

    nobody used that ^^

  467. Ge0rG

    lovetox: my father-in-law used that, before I gave him ChatSecure. At least MMS was working.

  468. Ge0rG

    besides, telcos will go a long way to protect their revenue model. One of the reasons Windows Phone failed was that telcos feared it would come bundled with Skype

  469. ralphm

    RCS is much much older than 2012.

  470. Ge0rG

    ralphm: but that's when it emerged to the general public and made everybody realize how big it's going to fail.

  471. ralphm

    I.e. it builds on IMS, which started in 1999 or so.

  472. ralphm

    Yeah, I can only hope that with Google touching it, it will be truly dead soon.

  473. Andrew Nenakhov

    Average Google service lifespan is like 1400 days... So this RCS will likely be over by 2023

  474. Andrew Nenakhov

    Source for lifespan: https://www.theguardian.com/technology/2013/mar/22/google-keep-services-closed

  475. ralphm

    I don't Allo is that old

  476. ralphm

    (think)

  477. Andrew Nenakhov

    For some it happens sooner. That's why it is called "average" )

  478. Andrew Nenakhov

    Allo is 3 years old I guess

  479. dwd

    21 Septmeber 2016, apparently.

  480. dwd

    So 18 months.

  481. Andrew Nenakhov

    Actually reading that link I remembered how much I liked Google Wave

  482. ralphm

    Hah, Google Wave's federation effort was one guy.

  483. Andrew Nenakhov

    Oh, I recalled that it was announced in spring event, but not in 2015 but in 2016, so it's closer to 2 years

  484. ralphm

    (and yes, I have the t-shirt)

  485. dwd

    Andrew Nenakhov, Announced in Google I/O 2016 (Spring?) but not launched for months afterward.

  486. Andrew Nenakhov

    Well, if you have 5 (6?) competing messaging services, it's quite probable they'll have shorter than average lifespan 😂

  487. ralphm

    Too bad I was busy at work today, but I love debunking comments on HN. Like this one https://news.ycombinator.com/item?id=16882916

  488. moparisthebest

    "it’s driven by the same companies that charge the equivalent of $1000+/mb for sms delivery" ha I never thought about it like that, excellent

  489. Ge0rG

    ralphm: I'm not sure which part of your comment is "debunking"

  490. ralphm

    Well, the argument that XMPP is too old

  491. ralphm

    But I guess my other comment is better

  492. Ge0rG

    ralphm: that was not an argument the OP made. They only wrote that XMPP failed, without a root cause analysis

  493. ralphm

    It was implied, I think, but sure

  494. Ge0rG

    ralphm: I'm not sure about that.

  495. ralphm

    People on HN generally use two arguments against XMPP: 1) too old, 2) xml/battery

  496. Zash

    You forget those who go "lalalallaala, matrix is the best!!"

  497. Zash

    and "matrix is winning because bridges"

  498. pep.

    daniel, seems interesting!

  499. Ge0rG

    Zash: we need a matrix bridge to rule them all

  500. pep.

    (goulash programming thing)