XSF Discussion - 2018-05-31


  1. jonasw

    Kev, I heard swift can do XEP-0055 (Jabber Search). Does it support RSM-based pagination and if so, where is the RSM element included? And if not, do you think RSM would be a reasonable way to do that and if so, where would the RSM element go?

  2. Kev

    It does 55, I don't believe we RSM.

  3. jonasw

    I’d very much like to not return 4000 entries in one reply though

  4. Kev

    I don't think 55 supports RSM does it?

  5. jonasw

    does *anything* before XEP-0059 "support" RSM?

  6. jonasw

    oh look at this, XEP-0059 even uses XEP-0055 as example for RSM

  7. jonasw

    and it’s allegedly used with disco#items

  8. jonasw

    (even though I haven’t seen that in the wild with MUC services yet)

  9. goffi

    I though RSM could be applied anywhere without need to specify it. This this was we answered to me when I asked for disco in the past.

  10. jonasw

    (AFAICT)

  11. goffi

    I thought RSM could be applied anywhere without need to specify it. This this what was answered to me when I asked for disco in the past.

  12. jonasw

    is there any standard for something like XEP-0055 (Jabber Search) but for MUCs? (not disco#items)

  13. goffi

    jonasw: what prevent you from using XEP-0055 with MUC ? It returns jid and can use data form for any extra data you wish.

  14. jonasw

    goffi: sure, I can re-use bits of 55 but I was wondering whether there was any precedent for that

  15. Guus

    Board o'clock

  16. MattJ

    Hey

  17. Guus

    o/

  18. Guus

    ralphm, martin, nyco ?

  19. ralphm

    I am here, was held up

  20. ralphm set the topic to

    XSF Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

  21. Guus

    yey

  22. ralphm bangs gavel

  23. ralphm

    1. Welcome & Agenda

  24. ralphm

    Who's here and what topics do you prefer to discuss today?

  25. Guus

    I'm here

  26. MattJ

    I'm here

  27. MattJ

    We can discuss the next steps for the results of the survey

  28. Guus

    Also: gdpr compliance?

  29. ralphm

    Cool. Maybe revisit the GDPR discussion

  30. ralphm

    That should fill most of the meeting.

  31. Guus

    also: did anyone hear from Martin in the last few weeks?

  32. Guus

    he didn't renew XSF membership - I wonder if that was intentional.

  33. ralphm

    Not since May 3.

  34. MattJ

    Likewise

  35. ralphm

    While there's no requirement to be a Member to be a Director, I share your curiosity.

  36. ralphm

    2. Survey.

  37. MattJ

    The survey "officially" ended yesterday, with 24 responses

  38. MattJ

    Which I don't consider too bad, I was expecting worse

  39. MattJ

    I haven't had time to do anything with the responses, barely look at them. I propose I do that and share a Google Spreadsheet over email, and we can discuss in more detail next week?

  40. MattJ

    and if anyone has specific things they'd like to discuss (e.g. points raised) we can add those to the agenda

  41. Guus

    Sounds good to me.

  42. ralphm

    Agreed

  43. ralphm

    3. GDPR

  44. ralphm

    So there a few things here and maybe we should split them.

  45. ralphm

    1) the XSF's compliance

  46. ralphm

    2) the proposed XEP

  47. MattJ

    Agreed, sensible

  48. Guus

    this feels like a beast: can we further split them?

  49. ralphm

    Go aheah

  50. Guus

    I would if I knew how 🙂

  51. ralphm

    Well, there are a few things on 1)

  52. ralphm

    - The foundation membership

  53. ralphm

    - The e-mail archives

  54. ralphm

    - The XMPP server with its rooms and archives

  55. ralphm

    shout if you can think up more items

  56. Guus

    that is: items where we potentially store private information?

  57. Guus

    do we use cookies on the website?

  58. MattJ

    s/private/personal/

  59. ralphm

    personal, indeed

  60. Guus

    Matt just asked for everyone's mail address in a nice (but one-off) poll

  61. MattJ

    I also stated how they would be used, and that they would not be kept permanently

  62. ralphm

    We can probably continue doing all the things we do, but we have to document what we process, for what reason, etc.

  63. Guus

    ok, stepping back: I'm unsure what exactly the end-goal is (other than 'be compliant' which I don't know what that entails)

  64. ralphm

    And we need to revisit/reinstate the Privacy Policy that was written in 2008

  65. Guus

    (we've got personal data in the wiki too, probably - and there's author information in each XEP)

  66. ralphm

    (for a discussion on this, see the archives of this room -1W)

  67. ralphm

    I also thought about the Wiki indeed, and the XEP

  68. ralphm

    s

  69. Guus

    I was knee-deep in water at the time, have not read back 😕

  70. ralphm

    Basically we had a PP for both jabber.org and xmpp.org, but with all the website transitions it is no longer available

  71. ralphm

    we have it somewhere still, though

  72. Guus

    okay, say we are able to restore that: is there someone available that can tell if it is GDPR compliant?

  73. ralphm

    First of all, no-one probably is 100% compliant, and you will know when somebody has sued you

  74. MattJ

    Nobody can really say for certain, there are too many grey areas - however I'm really not worried

  75. MattJ

    Pretty much all we have is public, and given by people knowingly

  76. ralphm

    The focus points will be documentation, the pp, and possibly retention, and information and deletion requests.

  77. MattJ

    There may be hidden things like server logs, but if we don't keep those for "too long", we "should" be ok

  78. Guus

    sure, and although I assume that that's ok, that's not based on any knowledge of gdpr on my part.

  79. ralphm

    Well, I've been involved professionally, so I know a few things

  80. Guus

    good. Tag, you're it. 🙂

  81. ralphm

    I think we should also involve Alex

  82. ralphm

    haha, good one

  83. ralphm

    Sounds like MattJ knows things, too

  84. Guus

    maybe we should task a certain group of people with doing an inventory of our data, and make recommendations?

  85. MattJ

    iteam?

  86. Guus

    or an adhoc one (Ralph, Alex, the people that have bene working on the XEP)

  87. Guus

    I'd be happy to do leg-work, but I need someone to tell me what to do.

  88. MattJ

    Well in the case I gave (server logs), that's something that requires iteam - an inventory of running services and what they collect

  89. Guus

    RIght - that's why I suggest to have a SIG or WT with people like yourself that know what to look for. A small group of people that maintains an overview, and coordinates efforts with other WTs and board.

  90. ralphm

    I think a work team

  91. Guus

    This all might be me being overcautious, based on a lack of understanding - if you see a way to shorttrack things, that's also fine by me.

  92. ralphm

    so indeed, you need iteam for inventory, someone the leads the effort, and in any case the Secretary should be involved

  93. ralphm

    There are probably helpful 10-step plans out there, but I haven't looked at that at all

  94. Guus

    I'm unsure if we can volunteer the Secretary for a WT, but we can at least ask the WT to inform the Secretary. 🙂

  95. Guus

    Ralph, would you mind spearheading that team?

  96. Guus

    you seem to have a good grasp on tings.

  97. Guus

    things*

  98. ralphm

    On the involvement of the Secretary, probably yes we can volunteer him:

  99. ralphm

    Section 6.7 Secretary. Unless provided otherwise by a resolution adopted by the Board of Directors, the Secretary shall keep accurate records of the acts and proceedings of all meetings of the Members and Directors. The Secretary shall give all notices required by law and by these Bylaws. He or she shall mail to all Directors within thirty (30) days after each meeting copies of all said actions and minutes of said proceedings. In addition, the Secretary shall have general charge of the corporate books and records and of the corporate seal, and he or she shall affix, or attest the affixing of, the corporate seal to any lawfully executed instrument requiring it. The Secretary shall have general charge of the membership records of the Corporation and shall keep, at the principal office of the Corporation, a record of the Members showing the name, address, telephone number, facsimile number and electronic mail address of each Member. The Secretary shall sign such instruments as may require his or her signature and, in general, shall perform all duties as may be assigned to him or her from time to time by the Chair, the Executive Director or the Board of Directors.

  100. ralphm

    Note the part on 'corporate books and records'

  101. Guus

    Let's aim to have a mission statement / member list ready for next week, so that we can procedurally establish the team.

  102. ralphm

    But of course we should ask Alex how he can help us on this

  103. ralphm

    seems reasonable

  104. ralphm

    Ok then, I guess we should move on to the other part

  105. ralphm

    4. GDPR XEP

  106. Guus

    (I don't have much more time to spend today)

  107. ralphm

    Oh, it is that time already.

  108. Guus

    as for the XEP: what are downsides of publishing such a XEP?

  109. ralphm

    Well, in principle it is unclear if the XSF should publish a specification that would give guidelines in direct relation to the GDPR

  110. ralphm

    I'm not familiar with US law, but the concept of Legal Advise is a apparently a Thing

  111. ralphm

    Advice even

  112. Guus

    what is "giving legal advice" ? Does publishing that XEP qualify?

  113. ralphm

    Well, in the state that it was in last week, there wasn't much in there yet

  114. ralphm

    I haven't checked since

  115. MattJ

    It's a combination of factors - for example, in some places you need to be licensed to practice law

  116. ralphm

    But I think it is more important for any such document to provide general guidelines in terms of knowing what you process and what things to take into account to ensure privacy for your service, and leave the rest up to people who Know Things (typically lawyers) for actual compliance

  117. MattJ

    It's a stretch, but if it was taken as the XSF is giving legal advice without being qualified to do so, that's illegal in those $some_places

  118. Guus

    My perspective is that I'd prefer to help the XMPP community by providing information, as long as a) we're not opening ourselves up to liability, and b) we can somehow be reasonably certain that we're not spreading misinformation.

  119. MattJ

    and separate from this issue, but similar - someone could try to blame the XSF if they followed published advice but got fined under GDPR

  120. Guus

    There's a huge gap between practice law and give information

  121. ralphm

    Right, so as Peter has suggested, and I agree with, I'd like any such document to be actual best practices, not related to any particular legislation

  122. Guus

    that's reasonable

  123. MattJ

    Me too

  124. Guus

    ok, I need to be going now

  125. Guus

    can we pick this up next week?

  126. ralphm

    Sure

  127. ralphm

    4. Date of Next

  128. ralphm

    +1W

  129. ralphm

    5. Close

  130. ralphm

    Thanks all.

  131. ralphm bangs gavel

  132. MattJ

    Thanks

  133. ralphm set the topic to

    XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

  134. Guus

    woah, I alt-tabbed for two seconds 🙂

  135. Guus

    thank you 🙂

  136. ralphm

  137. ralphm

    Also, I'm sure I used 4 two times, so whoever is making the Minutes (*wink*) should take that into account

  138. goffi

    would not it be possible for the XSF to hire some legal advisor to create a document? I mean this is expensive for a single project, but if XSF is hiring one describing general helping document, we could do some kind of crowdfunding among XMPP community. Maybe FSF have some helpful contacts

  139. goffi

  140. flow

    I'm pretty sure I've asked years ago on standards@ if an IQ send to the own bare JID is semantically equivalent to the same stanza without a 'to' attribute, but my google-fu is not strong enough to find that thread again

  141. Kev

    The answer is "yes". Also "no".

  142. Kev

    It is the same, except that there's some odd text still lying around that hints otherwise, like that roster queries must be no-JID (rather than bare-JID), maybe?

  143. flow

    I feared that this was the conclusion back then

  144. Zash

    Can we have that odd text accidentally dropped down a well?

  145. flow

    would a MAM IQ to the own bare JID be equal to the same query without to attribute?

  146. Kev

    flow: Yes.

  147. flow

    *without 'to' attribute

  148. MattJ

    As far as I'm concerned, and Prosody is concerned, yes

  149. Zash

    Prosody treats to=own bare jid identical to missing to

  150. daniel

    Can we just get rid of missing to and missing froms

  151. Zash

    In fact, it removes the 'to' and uses its absense for security related things

  152. Zash

    daniel: make them mandatory always, like on s2s?

  153. flow

    Zash, interesting, care to elaborate on these "security related things" that you get when you handle stanzas without 'to'?

  154. MattJ

    daniel, in a way I prefer it, you know this stanza isn't going anywhere

  155. daniel

    Zash: yes. If you want to send something to your account you have to address it

  156. daniel

    And vice versa

  157. MattJ

    flow, these stanzas are typically special in most XEPs (from user to their own account), they are privileged and Prosody handles them separately from normal stanzas that are to be routed

  158. Zash

    daniel: I want the opposite

  159. MattJ

    and we normalize the to/from to 'missing to' so that there can't be any JID normalization accidents in modules

  160. Zash

    And then it bites Ge0rG right in the carbons

  161. daniel

    MattJ: but if you address your server the stanza isn't going anywhere either...

  162. daniel

    For some definition of not going anywhere

  163. Kev

    MattJ: Do you do some sort of NAT to get the right address injected when you reply then?

  164. Kev

    Because replying to a to=bare stanza with missing to isn't ok.

  165. MattJ

    Kev, 'from' is always set, and that's what we reply to

  166. MattJ

    and 'to' is not needed on c2s streams

  167. Kev

    Because replying to a to=bare stanza with missing from isn't ok.

  168. Zash

    to and from should default to the entities on each end of c2s streams, ie the client and their account

  169. MattJ

    Obviously from and to are swapped in any reply

  170. Kev

    One has to be fairly careful when claiming anything is obvious, when talking about this ;)

  171. jonasw

    Kev, why is it not ok? missing from is identical to comes from bare jid, isn’t it?

  172. Zash

    client sending <message> == <message from=ownfulljid to=ownbare>

  173. jonasw

    (missing from when server sends)

  174. jonasw

    oh okay, MUST include the from attribute

  175. jonasw

    I am /pretty/ sure that I’ve seen servers which do not do that.

  176. jonasw

    I have ugly workarounds for that

  177. jonasw

    ah, no I am at the wrong place in the text

  178. Zash

    Whowhere?

  179. jonasw

    3. When the server generates a stanza from the server for delivery to the client on behalf of the account of the connected client (e.g., in the context of data storage services provided by the server on behalf of the client), the stanza MUST either (a) not include a 'from' attribute or (b) include a 'from' attribute whose value is the account's bare JID (<localpart@domainpart>).

  180. jonasw

    Kev, so, there’s no NAT needed, just don’t emit the @from in the reply ^

  181. daniel

    Zash: hoover?

  182. Kev

    jonasw: Yes, but if it's a reply to a stanza the client sent, the server must swap the to/from.

  183. Zash

    🕴

  184. Kev

    You can't, as a server, receive a stanza that is to=bare JID, and reply with no from.

  185. MattJ

    Kev, says?

  186. Zash

    The holy text.

  187. Kev

    MattJ: 6120, somewhere.

  188. Kev

    e.g. for error stanzas "The error stanza SHOULD simply swap the 'from' and 'to' addresses from the generated stanza"

  189. MattJ

    That's a stretch to say it applies to all stanzas, as you're saying

  190. Kev

    Yes, that was just the quickest thing to find.

  191. MattJ

    I think the text jonasw pasted is pretty clear that the server has two valid options

  192. Kev

    Yes, but not clear that both are always right.

  193. MattJ

    Then that text might as well be removed, and let the text you remember specify what the 'from' should be

  194. jonasw

    Kev, ok, then I found a server with a bug.

  195. jonasw

    because that’s why I needed workarounds (because servers did exactly that)

  196. jonasw

    ah, well

  197. jonasw

    if the swap is only a SHOULD, I can see this to be an exception

  198. Kev

    I can't find the odd text about rosters now on a quick search either, so there's clearly text I'm failing to find.

  199. Kev

    jonasw: We have handling too, in https://github.com/swift/swift/blob/master/Swiften/Queries/Request.cpp#L79

  200. Kev

    (In fact, we have further workarounds for ejabberd issues where they used to reply with full JIDs)

  201. jonasw

    oh yes

  202. jonasw

    I love those

  203. koyu

    hey, i just setup my own xmpp server

  204. Kev

    Welcome to the cool club. Or something.

  205. MattJ

    :)

  206. koyu

    yeah, i just can't get omemo to work on ejabberd

  207. Wiktor

    As far as I remember omemo is disabled by default in ejabberd, but you may check in ejabberd room

  208. Wiktor

    xmpp:ejabberd@conference.process-one.net?join

  209. jonasw

    Ge0rG, chat.yax.im down?

  210. Ge0rG

    jonasw: works for me

  211. jonasw

    yeah, it just had a few minutes of hangup

  212. jonasw

    17:04:14 <--- You (jonasw) left the room (the MUC server is not responding) 17:07:17 ---> You (jonasw) joined the room

  213. jonasw

    (or maybe it was just the link between us. who knows)

  214. MattJ

    So MIX proxy JIDs... if someone creates a MIX channel that is <1023 bytes>@mix.example.com... what happens to the userid part?

  215. jonasw

    "boom"

  216. jonasw

    I imagine servers simply wouldn’t allow that

  217. MattJ

    So how long is the generated id?

  218. jonasw

    probably service-defined

  219. MattJ

    It's such a hack

  220. jonasw

    do you have a better suggestion?

  221. MattJ

    Well instead of overloading what should be an opaque identifier why not re-use a mechanism that is already in the protocol as a secondary identifier behind bare JIDs?

  222. jonasw

    because that leads to the same situation

  223. jonasw

    just in a different part and with different moving parts

  224. jonasw

    with Kevs variant (1), the multiple pieces are in the nodepart, with variant (2) the multiple pieces are in the resource

  225. jonasw

    so both are bad w.r.t. that

  226. jonasw

    one way out of that would be to use $service-wide-user-id@$service-domain/$resource instead (so the MIX identifier wouldn’t be part of the node at all). but that requires to have the JID of the MIX inside the relevant stanzas

  227. MattJ

    All existing routing, libraries and... everything already knows how to correctly split a JID

  228. jonasw

    true

  229. jonasw

    and I think that the semantics assumed with "bare JID" work better with variant (1) than with variant (2)

  230. MattJ

    Trust me, someone will want to implement some higher-level logic to know which messages are associated with a MIX channel

  231. MattJ

    Except with variant (1) you can't really do that

  232. MattJ

    You have to know it *is* a MIX channel, and that you have to strip the bit before the #

  233. MattJ

    Block a MIX channel? Ok, but messages from participants would still reach you

  234. jonasw

    and other people want to have high-level logic to konw which messages are associated with a MIX channel occupant.

  235. MattJ

    any kind of filtering or logic based on the channel JID now almost always will need to be adapted to look for the # part

  236. jonasw

    we should’ve followed email and allowed multiple @s in addresses

  237. MattJ

    Yes, that would really have helped... :)

  238. MattJ

    so now nobody knows what an email address actually is, but everyone has their own idea that's good enough for them

  239. MattJ

    Pretty much what's going on here, to be honest :)

  240. MattJ

    The # is the extra @ to the entities that can see it

  241. MattJ

    To the others, it's not and it's weird

  242. jonasw

    the variant (2) would make things worse than MUC actually

  243. MattJ

    Can you (or someone) lay down the reasons for that?

  244. jonasw

    didn’t I?

  245. MattJ

    I didn't see if you did, /me checks

  246. jonasw

    but the point which I just realized is, that with variant (2), there’s no single JID which will ever occur in a message identifies an occupant

  247. jonasw

    so if you wanted to filter all messages from an occupant, you’d have to know that they’re MIX messages

  248. jonasw

    to split them correctly

  249. jonasw

    kinda the same issue you describe with MIX channels in variant (1)

  250. MattJ

    Hmm, what do you mean?

  251. jonasw

    for example, presence

  252. jonasw

    and avatar hashes

  253. jonasw

    I keep those in a cache, usually keyed by the bare JID

  254. jonasw

    which I can’t do for MUC, I have to use the full JID, but that’s okay

  255. jonasw

    (I actually have to break layers to detect that a presence is MUC related at that point)

  256. jonasw

    now with MIX, it’s worse, because not only do I have to check that it’s MIX-related, I also have to use a non-RFC6122 splitting function on the JID to determine the cache key

  257. jonasw

    i.e. do determine the identity this JID belongs to

  258. jonasw

    really, the same thing you described earlier, just with occupants instead of channels

  259. MattJ

    Right

  260. jonasw

    I think your issue is more server-side and my issue is more client-side, actually, and that might be why we see them strongly each

  261. jonasw

    (clients may be more interested in occupant identities, while servers may be more interested in channel identities because that’s the granularity they work on)

  262. MattJ

    So how do you know it's a MIX message and you need to split the nodepart? Payload?

  263. jonasw

    yes

  264. jonasw

    Strawman proposal: - proxy JID does not contain the MIX channel, but only the proxy identifier in the nodepart - resource as usual - MIX channel is identified in payload, e.g. <message from="ac2c37a7-10a6-4cd7-a708-4973d5d365f8@mixservice.domain.example" to="user@other.example" type="groupchat"><mix channel="..."/></message>

  265. jonasw

    Strawman proposal: - proxy JID does not contain the MIX channel, but only the proxy identifier in the nodepart - resource as usual - MIX channel is identified in payload, e.g. <message from="ac2c37a7-10a6-4cd7-a708-4973d5d365f8@mixservice.domain.example/client-resource" to="user@other.example" type="groupchat"><mix channel="..."/></message>

  266. MattJ

    Heh, part of me wants to dislike that, but I prefer it

  267. MattJ

    I feel like the security aspects need to be investigated here though

  268. jonasw

    that’s not how straw-mans are supposed to work

  269. jonasw

    which part exactly?

  270. MattJ

    Well you need to verify the service in every case, I think

  271. jonasw

    what do you mean exactly?

  272. MattJ

    Otherwise I register mattj#rocks@jabber.org and send you a message wih a MIX payload

  273. jonasw

    and then?

  274. MattJ

    Don't know, currently I got as far as "your client breaks"

  275. jonasw

    the client or server would drop it because it doesn’t know about a MIX rocks@jabber.org

  276. jonasw

    just like we currently drop type="groupchat" from MUCs we don’t know.

  277. MattJ

    Right, the whole "participant's server needs to know MIX" thing

  278. jonasw

    at least we’re honest about it this time (not with MUC, where servers were blindsided by interesting interaction sideeffects e.g. when changing nicknames)

  279. jonasw

    at least we’re honest about it this time (not like with MUC, where servers were blindsided by interesting interaction sideeffects e.g. when changing nicknames)

  280. MattJ

    I like your straw-man because it opens up the possibility for a user on a MIX service to have a stable JID across multiple channels

  281. jonasw

    I’m not sure that’s a good thing

  282. jonasw

    but mmm, it could be

  283. jonasw

    it makes it more difficult for MIX services though

  284. MattJ

    How so?

  285. jonasw

    when I send a message to ac2c37a7-10a6-4cd7-a708-4973d5d365f8@mixservice.domain.example, they need to verify that I share a channel with them

  286. jonasw

    (or may need to, depending on the service policies; but I assume that this is how most services will want to operate)

  287. jonasw

    hm, or we require <mix channel="…"/> elements even in non-groupchat messages

  288. jonasw

    then the sender would assert through which channel this message shall be "tunneled" and the server would not have to form the intersection of both channel lists

  289. jonasw

    question is whether that’s reasonable

  290. MattJ

    Totally if you ask me

  291. jonasw

    so I’ll post that to the list now

  292. MattJ

    Variant 3! Thanks :)

  293. jonasw

    Advantages: - No re-write of resources - Bare JID refers to occupant identity (good for clients) - Servers can simply filter on message/mix@channel - Opens up the possibility of re-using the same proxy JID for the same occupant across different channels (may be useful in some deployments, via MattJ) Disadvantages: - All (including 1:1) stanzas exchanged between occupants require the <mix channel="…"/> element for MIX channels to be able to easily route them - Entities filtering on MIX channel identity still need to know about MIX (and the <mix channel="…"/> element)

  294. jonasw

    did I miss something?

  295. jonasw

    sent

  296. MattJ

    Sorry, lgtm

  297. Kev

    I'll reply properly onlist in the morning, but now you need to do DPI to be able to routing in your client, because the routing information is no longer in the header? That's terribly unpleasant.

  298. Kev

    I'll reply properly onlist in the morning, but now you need to do DPI to be able to do routing in your client, because the routing information is no longer in the header? That's terribly unpleasant.

  299. Kev

    i.e. I think option 3 is the worst of the three.

  300. Kev

    (And possibly worse, your server needs to be doing DPI in order to make archiving work)

  301. jonasw

    Kev, don’t you need to do DPI anyways because you need to be sure you’re looking at a MIX message?

  302. jonasw

    (otherwise, the "MIX JID splitting function" (whatever that is) would operate on non MIX JIDs and possibly yield wrong results)

  303. Kev

    No, you don't :)

  304. jonasw

    servers need to do DPI anyways today for archiving to work.

  305. Kev

    Not at this level.

  306. jonasw

    normally, type="groupchat" isn’t archived at all, right?

  307. Kev

    That obviously has to change.

  308. jonasw

    for MIX, yes

  309. Kev

    type=groupchat to the bare JID gets archived.

  310. Kev

    (Once routing/archiving rules are fixed)

  311. jonasw

    right

  312. jonasw

    that would work

  313. Kev

    I have to sort out bins and then go to bed, but I think option 3 has worse issues than the conflation in option 1/2.

  314. jonasw

    looking forward to your reply

  315. jonasw

    and the discussion :)