XSF Discussion - 2017-11-25

  1. jjrh has left
  2. Zash has left
  3. Valerian has joined
  4. Zash has left
  5. Zash has joined
  6. sonny has joined
  7. arc has left
  8. arc has joined
  9. Valerian has left
  10. arc has left
  11. arc has joined
  12. efrit has left
  13. Holger has left
  14. arc has left
  15. arc has joined
  16. vanitasvitae has left
  17. Zash has left
  18. arc has left
  19. arc has joined
  20. vanitasvitae has left
  21. ralphm has left
  22. blabla has joined
  23. jjrh has left
  24. blabla has left
  25. jjrh has left
  26. la|r|ma has joined
  27. lumi has left
  28. Steve Kille has left
  29. sonny has joined
  30. sonny has joined
  31. jjrh has left
  32. jjrh has left
  33. Steve Kille has left
  34. jjrh has left
  35. uc has joined
  36. tux has left
  37. tux has joined
  38. jjrh has left
  39. jere has joined
  40. jere has joined
  41. matlag has left
  42. xnyhps has joined
  43. xnyhps has joined
  44. jjrh has left
  45. jjrh has left
  46. jjrh has left
  47. Zash has left
  48. jere has joined
  49. jjrh has left
  50. jjrh has left
  51. arc has left
  52. arc has joined
  53. arc has left
  54. arc has joined
  55. mimi89999 has left
  56. mimi89999 has left
  57. mimi89999 has joined
  58. uc has left
  59. uc has joined
  60. arc has left
  61. arc has joined
  62. Arc has left
  63. Arc has joined
  64. arc has left
  65. Zash has left
  66. arc has joined
  67. sonny has joined
  68. zinid has joined
  69. zinid has joined
  70. goffi has joined
  71. jjrh has left
  72. jjrh has left
  73. Guus has left
  74. arc has left
  75. arc has joined
  76. arc has left
  77. arc has joined
  78. Arc has left
  79. valo has left
  80. valo has joined
  81. Ge0rG has left
  82. Ge0rG has left
  83. arc has left
  84. arc has joined
  85. Arc has joined
  86. Syndace has left
  87. Syndace has joined
  88. Syndace So, starting off a topic that might be even worse than banning someone: Why is the discussion about omemo completely silent? I remember a few weeks (months?) ago someone wrote a mail asking about a technical change in the protocol to move from a signal-only technique to some wide-spread alternative and I was really hyped to contribute to this discussion but then nobody replied and the thread just died. So what's the thing about omemo? Why is there no heated discussion? I see two pull requests in the xsf repo just gathering dust.
  89. Syndace Oh I should add I have'nt read the chats in about two weeks, I may have missed something recently.
  90. Flow What Holger said. Besides Zinids choice of words, I did not notice him insulting someone.
  91. Flow Syndace, I guess there current OMEMO implementations are happy with they way they are
  92. Flow *the current
  93. Flow At least I have no incentive to work on an OMEMO-NEXT which just changes a crypto primitive for another one, when I think the current primitive is perfectly fine for all use cases.
  94. Arc has left
  95. Steve Kille I thought that Ralph made a good call here
  96. Syndace Huh, that answer is not satisfying. The current stadard just tells people to use lib signal without having any actual alternative or even knowing the insides of the protocol. I thought the goal was to move away from libsignal asap, as it is GPL3'd and not maintained by us. If we ever decide to change something about omemo that does not comply to the way lib signal currently works we have a lot of trouble.
  97. Flow Steve Kille, I think the ban was at least borderline. Asking someone to be polite, sure. But otherwhise people could just "/ignore Zinid"
  98. ralphm I don't understand. There's a difference between a protocol and a library in terms of licensing.
  99. ralphm Flow: FWIW, I already lifted the ban
  100. Flow Syndace, That is why we had Andy's PR which was an attempt to move away from "protobufs as libsignal does them" towards "those are the fields and this is how we put them into XML"
  101. ralphm If he keeps it up, though, I'll waste not so many words as yesterday.
  102. Flow ralphm, yeah, there is a difference between a protocol and a library in terms of license, but the fact that all libsignal impls are GPL'ed was brought up again and again
  103. Flow it was especially XEdDSA which is part of libsignal
  104. ralphm Sure. So either someone does a clean room implementation with a different license, or something new happens. This is nothing new?
  105. Flow IIRC
  106. Flow ralphm, yeah, but why make something new if XEdDSA is an open specification
  107. ralphm We've marked specifications as 'historical' instead of 'standard' before for reasons like that.
  108. ralphm Flow: I agree. But then the only obstacle is, well, doing something?
  109. Flow ralphm, I'm sorry, only had my first cup of coffee, I can't follow
  110. Syndace Flow, not something new but something that is included in 90% of all crypto-libraried you can find in the wil
  111. Syndace wild*
  112. Syndace instead of something that does the same and has just one single implementation out there
  113. Flow Syndace, there are multiple
  114. ralphm Flow: my point is that a library license is not necessarily interesting for defining a protocol. It might be for adoption, though. If someone cares enough, that problem goes away. If people just keep complaining instead, it doesn't.
  115. Flow ralphm, I think you are saying what I've been saying the whole time
  116. ralphm I happy to be in violent agreement.
  117. ralphm I'm
  118. Syndace Flow, are you sure it's not all just ports of the singal implementation? I'm having a hard time finding another one on google.
  119. Flow But unfortunately, the unwritten (?) "there can only be once experimental XEP for $foo" philosophy has stopped the effort to standardize OMEMO based on the open signal specifications
  120. Flow Syndace, it's still multiple implementations, no?
  121. daniel Syndace: do you have stakes in this? Do you maintain a client or something? If so implement something, spec something and propose this
  122. daniel In my experience change does come from discussing things to dead but from implementing and specing it out
  123. daniel *doesn't
  124. Flow "change does come from discussing things", hehe if that where true we had a long of change in XMPP-land ;)
  125. Flow yeah, but daniel is essentialy right, to many specs, and that includes MIX, make to much spec progress without an accompaning impl
  126. daniel *cough* OK
  127. daniel OX
  128. daniel Dann it i can't type. I need coffee
  129. ralphm Flow: I don't recall such a policy. We've had multiple competing experimentals at a time before.
  130. Flow daniel, hmm, well but I think the basics of OX are far less complex than e.g. MIX or OMEMO
  131. Syndace daniel, agreed, altough one of the pr's already includes the change I'm proposing. So what do you all think: If I publish a library which does omemo encryption without xeddsa first and THEN try to start the discussion again, will it change things and be more likely to actually move away from libsignal?
  132. Flow and there are at least two prototypcial impls I'm aware of
  133. ralphm in fact most of the current building blocks have had multiple different proposals. Disco (Browse, Agents), PubSub, Jingle (SI).
  134. Flow but yes, more OX impls for the greater good!
  135. ralphm Usually the driving force should be _running code_
  136. Flow ralphm, then we can continue working on what Andy proposed?
  137. ralphm I don't think anyone can (or would want to) block working on competing standards.
  138. ralphm For interop, though, eventually, one should prevail.
  139. Flow Cool, then we could also start work on a MIX competitor
  140. daniel > daniel, hmm, well but I think the basics of OX are far less complex than e.g. MIX or OMEMO Sure. I just meant to say it's not implemented
  141. Flow hands daniel a virtual cop of coffee while he gets a physical one for himself
  142. Kev has left
  143. ralphm You wouldn't be the first. The Erlang Solutions people have worked on MUC Light. I personally think that MIX is the way to go to eventually.
  144. ralphm MIX is of course comprehensive and there are a lot of moving parts before getting there.
  145. ralphm Making more focused protocols is always easier.
  146. Flow ralphm, yep, the MUC light situation come to my mind too. And I agree that ideally everyone would be working on the same thing. But for such a crucial building block as persisent groupchat, I wouldn't want to bet all my money on a single horse
  147. ralphm The thing I like about MIX most are a) relating occupants on bare JIDs, b) persistent occupancy, even if not online, c) extensible orthogonal streams
  148. daniel Flow, i'm personally came to believe that forward secrecy is totally unnecessary and kills UX and I would prefer something like OX actually. but I don't want to be the single driving force for something like this again. plus I lot of the change i'm trying to push with OMEMO (like proper access control on pubsub) will benefit OX as well.
  149. ralphm My pet peeve about, for example, Slack, is integrations messing up conversation in the same channel. With MIX an integration would be on a separate node, and a client can make choices on how to represent such streams in a different way.
  150. Flow daniel, good to hear that you would probably be interessted in OX for Conversations. I plan to do a OX sprint around march next year (our research project has an evaluation in january, so most people are panicing and there is a lots of stuff to do until then)
  151. Flow daniel, lovetux also wanted to improve they way keys are announced and stored
  152. daniel in OX?
  153. Flow yep
  154. daniel with a meta note?
  155. Flow so waiting after that has been spec'ed may be a good idea
  156. Flow yep
  157. daniel has left
  158. Flow (given we talk about the same meta node approach)
  159. daniel the real issue by the way is that we have to retrieve all pep notifications again and again on every login (instead of them landing in MAM for example) - meta or not that a lot of traffic
  160. Flow daniel, you can configure PubSub nodes to not do that
  161. daniel a login on my personal device with tens of people having avatars and omemo is really really expensive these days
  162. Flow (see my discussion in here with lovetux a few days ago)
  163. daniel Flow, will they be sent instead (and sent to mam) even if i'm offline?
  164. daniel because just not receiving updates at all doesn't solve the situation
  165. ralphm PEP is just a profile of PubSub with very specific use cases. If you want other behaviour for nodes-on-user-accounts, that's totally fine.
  166. ralphm And of course they can integrate just fine with MAM
  167. daniel ralphm, a) i know b) tell that to the prosody developers :)
  168. ralphm MattJ: ^
  169. ralphm :D
  170. Flow daniel, you want to search xep60 for pubsub#send_last_published_ite
  171. Flow m
  172. Flow daniel, I think so
  173. Flow (not sure about MAM, probably depends on the MAM service impl)
  174. jubalh has joined
  175. daniel in any case; making pep a proper pubsub child (in the implementations) and being able to configure something like access control and send_last_published_item and also storing them in MAM is some good preperation that OX, OMEMO and OMEMO-NEXT can all benefit from
  176. daniel thus far we haven't even managed to make publish_options work on all servers
  177. daniel at least we are getting there with ejabberd now
  178. Flow daniel, right but thats a spec vs impl thing
  179. Flow the only thing we can do from the spec side is to ensure that the required baseline profile is as minimalistic as possible
  180. Flow (looking at you MIX)
  181. Flow and that baseline should be ideally able to fullfil >85% of the use cases
  182. daniel Flow, yes sure. but I like to implement things in Conversations that will actually work so I need server side implementations
  183. daniel besides having access control would allow us to move bookmarks into pep and get other clients notified if one client changes things. imagine how great that would be if we could sync bookmarks across multiple devices in the year 2018
  184. Flow daniel, absolutely comprehensible
  185. Guus has left
  186. Flow just noticed that at next Summit/FOSDEM, drumpf will be president for >1 y
  187. jubalh has left
  188. xnyhps has joined
  189. Guus has left
  190. marc has joined
  191. daniel has left
  192. ralphm has left
  193. lumi has joined
  194. zinid > I think the ban was at least borderline you cannot ban anyone in XMPP :)
  195. zinid and ignoring is not implemented, so, deal with it ;)
  196. Holger has left
  197. Flow zinid, peozio supports /ignore (although I've never used it, and don't plan to do so)
  198. arc has left
  199. arc has joined
  200. daniel has left
  201. zinid Flow: nice
  202. daniel has left
  203. la|r|ma has joined
  204. Alex has joined
  205. lskdjf has joined
  206. Guus has left
  207. Guus has left
  208. ralphm has joined
  209. daniel has left
  210. fippo is there a new presence subscription spam wave?
  211. ralphm I did get a bunch over last week
  212. Ge0rG fippo: ongoing right now
  213. Alex fippo: yes, denied already 20 subscriptions today
  214. fippo word + three digits as username... now sure if there is a pattern in the resource but i would not expect any
  215. fippo fun :-/
  216. Alex yes, same pattern here
  217. daniel has left
  218. Steve Kille has left
  219. Guus I appear to be on a different list then
  220. daniel has left
  221. blabla has joined
  222. jere has joined
  223. blabla has left
  224. ralphm has joined
  225. Tobias has left
  226. daniel has left
  227. goffi has left
  228. ralphm has joined
  229. MattJ Ge0rG, master of all things XMPP 2.0, should headline/normal messages be archived?
  230. Zash has joined
  231. goffi has joined
  232. jabberatdemo has joined
  233. Ge0rG MattJ: yes/no in my current opinion, but this is subject to other factors I haven't thought through yet
  234. MattJ Oh really
  235. MattJ I'd have thought yes/no if both would be different
  236. MattJ headline is defined as transient, no offline storage, etc.
  237. MattJ *no/yes
  238. Ge0rG MattJ: right, no/yes
  239. MattJ ...
  240. MattJ Ok, we both made the same typo, that's ok then :)
  241. Ge0rG MattJ: but it would make sense to decouple persistence from type
  242. daniel wouldn't the full jid / bare jid approach work as well?
  243. Ge0rG daniel: yes, it's my preferred approach
  244. MattJ Mine too
  245. jonasw Ge0rG, I heard you on council now ;-)
  246. MattJ But until we can find a sensible transition path to full/bare, I'm sadly living in reality
  247. Ge0rG I've also updated my slide deck with the rfc routing rules, as those are complex enough already
  248. daniel MattJ, if that's about 0313 i wouldn't touch the rules regarding headline
  249. daniel for now at least
  250. jonasw could we change 0313 to the full/bare thing sensibly after it moving to draft?
  251. jonasw it is based on message types currently, I think that could be considered as a breaking change
  252. Ge0rG MattJ: can we change the MAM response message type to headline please?
  253. MattJ But the MAM responses are sent to the full JID :)
  254. Ge0rG Yes
  255. MattJ jonasw, don't worry, I'm not planning on coding any rules into XEP-0313 (which is currently intentionally very light on rules)
  256. jabberatdemo has left
  257. MattJ other than I think we all agree that groupchat shouldn't be archived
  258. Ge0rG But there are servers in the reality you just mentioned that will reroute full JID normal messages
  259. MattJ which are those?
  260. Guus has left
  261. MattJ because I thought that was in the spec
  262. Ge0rG MattJ: ejabberd, because it broke message delivery for Gajim users
  263. MattJ 6120 says: "If the JID contained in the 'to' attribute is of the form <localpart@domainpart/resourcepart> and the user exists but there is no connected resource that exactly matches the full JID, the stanza SHOULD be processed as if the JID were of the form <localpart@domainpart>"
  264. Ge0rG I'm sure we are going to experience funny effects with MAM MUC queries on ejabberd
  265. Ge0rG Ge0rG [21:49]: > So I've updated the "XMPP broken" presentation slides, including a screenshot. https://op-co.de/tmp/whats-wrong-with-xmpp-2017.pdf MattJ: ^
  266. MattJ Ok, this section is more detailed: https://xmpp.org/rfcs/rfc6121.html#rules-localpart-fulljid
  267. Ge0rG There is a table of the relevant cases
  268. MattJ What's the case for MAM results having type="headline"?
  269. Ge0rG MattJ: the ejabberd inconsistency and also that headline messages are ephemeral
  270. MattJ I'm not updating the spec for an implementation bug
  271. MattJ and I agree that in hindsight, headline has cleaner semantics for these messages, but is it worth another namespace bump?
  272. daniel MattJ, are you going to accept my PR so jonasw can merge it before we are getting caught up in trying to fix $everything?
  273. MattJ daniel, yes, sure
  274. jonasw s/jonasw/$editor/
  275. daniel MattJ, Ge0rG maybe put the headline thing on a todo in case we will do another ns bump anyway for some other reason
  276. MattJ FWIW I started this conversation with an innocent question that is not at all related to updating XEP-0313
  277. jonasw what about todo lists in XML comments in the xep files themselves?
  278. MattJ I'm working on code at the moment
  279. MattJ jonasw, that happens to be what I do locally :)
  280. jonasw :)
  281. daniel regarding the headline thing; I would like to have a situation where pep publish notifitcation messages can go to mam but the resend on login messages don't
  282. Guus has left
  283. daniel i'm not sure if they are addressed to bare-jid / full-jid respectively
  284. Ge0rG MattJ, daniel: I'm not sure we really need a namespace bump for the type change. Most client implementations don't care about it anyway
  285. zinid has left
  286. MattJ Most? What about the ones that do? :)
  287. Ge0rG MattJ: those haven't implemented MAM anyway yet? 😁
  288. Ge0rG Okay, I have no idea which clients explicitly filter on message type.
  289. Alex has left
  290. xram has joined
  291. Ge0rG And you really don't want MAM responses to end up in offline storage, do you?
  292. MattJ No, but as I understand it, that will only happen on ejabberd due to a bug
  293. MattJ and even then, it's not the end of the world
  294. MattJ If the client uses queryid, it won't get confused, and will just ignore them
  295. Ge0rG MattJ: a server implementation can store incoming normal messages to offline as well
  296. MattJ That's not what your table says
  297. MattJ 6121: "For a message stanza of type "normal", "groupchat", or "headline", the server MUST either (a) silently ignore the stanza or (b) return an error stanza to the sender, which SHOULD be <service-unavailable/>. "
  298. daniel > regarding the headline thing; I would like to have a situation where pep publish notifitcation messages can go to mam but the resend on login messages don't maybe that's more of an argument to make pubsub publish messages type=normal maybe headline should never be stored anywhere. else we will loose the difference between normal and headline
  299. Ge0rG MattJ: what does prosody do?
  300. Ge0rG MattJ: oh, you are right
  301. Ge0rG I think we need a new message type 'system'...
  302. MattJ Ge0rG, let's not talk about Prosody :)
  303. MattJ (looks like it treats chat/normal the same here)
  304. Ge0rG Though I must admit it probably won't happen in this universe
  305. MattJ and in my head, they were equivalent, and only headline was not stored
  306. Ge0rG MattJ: I'm already glad I took the time to make this table
  307. MattJ But it's a trivial fix
  308. MattJ Me too
  309. Ge0rG MattJ: it will break users' expectations
  310. MattJ No, because no users use type=normal :)
  311. nyco has left
  312. MattJ and if they do, they have expectations of it breaking
  313. Ge0rG MattJ: you can ask Holger, he fixed it as well, and had to revert almost immediately
  314. Ge0rG MattJ: users have no idea about message type
  315. Ge0rG MattJ: all they care about is that suddenly prosody broke message delivery
  316. MattJ What clients other that Gajim and Psi allow you to send type=normal?
  317. MattJ *than
  318. nyco has joined
  319. Ge0rG MattJ: I have no idea
  320. goffi SàT allows it and use normal messages
  321. MattJ So three clients so far. How many of those will send type=normal to the full JID?
  322. goffi (haven't read the whole log, just the last few lines, so I'm not sure what this is about)
  323. MattJ goffi, the spec says that type=normal to a full JID should not be stored as an offline message
  324. MattJ if the resource is offline
  325. goffi it's technically possible to send to full jid from SàT using command line, but I don't think there is a reason why a user would do that.
  326. Ge0rG MattJ: gajim was accidentally sending normal to full JID.
  327. goffi but I though only headline message were not stored offline?
  328. goffi thought*
  329. MattJ goffi, "I don't think there is a reason why a user would do that" - https://xkcd.com/1172/
  330. MattJ goffi, I thought that too (and Prosody does that)
  331. MattJ But seems we were all wrong
  332. MattJ Ge0rG, ok, surely that must be in the case that the recipient is online?
  333. MattJ Ge0rG, don't tell me it sends to a full JID when they are offline
  334. MattJ -> I'm curious what Holger fixed, and how it was noticed so quickly
  335. goffi MattJ: forgot this one :D
  336. goffi for the record there is an experimental plugin in SàT which allows to send and read messages through an email client (MUA), and this is case message of type "normal" can be filtered to be only readable from email client.
  337. Ge0rG MattJ: it doesn't matter whether the user is offline at the time of sending because RACE CONDITIONS!!!1!
  338. MattJ Ge0rG, yes, but this race condition wouldn't happen that often
  339. Ge0rG MattJ: please ask Holger for the details, and maybe also lovetox
  340. Ge0rG MattJ: I know Holger linked to the revert commit in here, some weeks ago, but I'm on my mobile now, and haven't implemented search yet
  341. MattJ ok
  342. Flow why is it so important what MAM services store, isn't it more important what they return on a query?
  343. MattJ They can't return stuff they don't store
  344. MattJ and there is a cost to storing *everything*
  345. Flow I can see that groupchat messages should not be returned on normal client catch-up, but does that automatically mean xep313 must forbid services storing them?
  346. MattJ Given that nowadays we're into replicating everything to every client, the optimal path is that everything we want on every client is what is stored
  347. MattJ and what we don't want on every client is not stored
  348. Alex has joined
  349. Flow MattJ, of course there is a cost, but I want total freedom for MAM services regarding what to store
  350. MattJ Then what you're asking is for the MAM service to be able to store stuff that is "hidden" from a default query
  351. zinid has joined
  352. MattJ I think that would be fine
  353. Ge0rG Flow: that's exactly what I wrote to the ML yesterday
  354. Flow MattJ, not strictly, but yes
  355. Flow I believe the construction site should be the MAM query mechanism, not the archiving rules
  356. Flow Although I also don't like the current MAM version to require services to store groupchat messages
  357. Ge0rG I'm not sure if the wording in the XEP speaks about what's stored or what's returned, but there's some room for a xep that stores more and provides an extension to query for that
  358. Ge0rG Unless we can make MUC work on an account, kind of like MIX light, there is no way for account local MUC archives
  359. MattJ Flow, the current version doesn't require that
  360. MattJ Oh wait, it does
  361. Flow MattJ, A server SHOULD also include messages of type 'groupchat' that have a <body>
  362. MattJ Yeah, sorry, that's what we discussed on the list
  363. MattJ I'm still surprised at that text :)
  364. Flow MattJ, no worries, $stuff's complicated
  365. MattJ Daniel made a PR to fix it anyway
  366. MattJ so it'll be gone soon
  367. Flow MattJ, IIRC Daniel PR no requires MAM services to not store groupchat messages
  368. Flow which is also not good IMHO
  369. MattJ Heh
  370. Flow *now
  371. Flow But you should now best, because you just approved it ;)
  372. Flow *know
  373. MattJ I think what you want is sensible, but shouldn't be part of the default query
  374. Flow A server SHOULD NOT include messages of type 'groupchat' in a user archive
  375. MattJ so in a sense the spec should separate the idea of storing something, from returning it in a query
  376. Flow MattJ, exactly
  377. MattJ I'm totally fine with that, just figuring out how to cleanly word that will be tricky
  378. Ge0rG MattJ: yes please
  379. MattJ PRs welcome
  380. MattJ I'm currently working on restructuring Prosody's message delivery code to make XMPP 2.0 stuff easier (this is the ongoing side project that includes the rewrite of mod_smacks)
  381. MattJ I'm fed up of missing messages from my wife because my phone battery was flat, and they got "successfully delivered" to poezio, which is online 24/7
  382. marc What's XMPP 2.0?
  383. MattJ Pretend I said something else
  384. Ge0rG MattJ: and this is why I'm using a separate account for my family communication for many years already
  385. jonasw marc, "Message Routing 2.0" is probably a more accurate term
  386. jonasw marc, there are a few issues with how XMPP message routing behaves with multiple clients online on the same account at different or the same times
  387. MattJ jonasw, but what a mouthful. We need a marketing term :)
  388. jonasw MattJ, sure, but we don’t need to market to marc, I think :)
  389. marc jonasw, ah okay, is this a XEP?
  390. jonasw marc, not yet
  391. jonasw marc, there’s some info on the wiki: https://wiki.xmpp.org/web/XMPP_2.0
  392. jonasw (which may be slightly outdated)
  393. jonasw and also a bunch of discussion on the mailinglist
  394. Ge0rG And my slide deck
  395. MattJ marc, most comprehensive source of information is: https://op-co.de/tmp/whats-wrong-with-xmpp-2017.pdf
  396. Ge0rG MattJ: thanks
  397. marc jonasw, MattJ thanks!
  398. MattJ marc, "XMPP 2.0" isn't anything formal, and doesn't exist. We're just doing some review of where we are, and where we are going, and what feasible changes we can make to the protocol to make everyone's lives easier
  399. MattJ Back when XMPP/Jabber began, most of the popular IM networks would disconnect you from one location if you logged on from a new location
  400. MattJ XMPP supported multiple connections long before everyone had smartphones, laptops, etc.
  401. MattJ and back then, it aimed to do clever things like figure out which device you wanted to receive messages on
  402. Arc has joined
  403. zinid Now this is not required and even detrimental
  404. marc MattJ, I understand and I'll read the slides etc. to be up-to-date, thanks :)
  405. Flow MattJ, I always wonder if that priority based routing was clever even 10 years ago
  406. Flow Or what that rationale for that back then was
  407. Ge0rG marc: ping me if you have questions about the slides. I gave them to a nerd friend recently and had to realize they are not meant for people without really deep understanding of XMPP
  408. marc Ge0rG, will do :)
  409. Alex has joined
  410. ralphm Flow: the idea back then didn't take into account ubiquitous mobile devices
  411. Kev has joined
  412. ralphm It was assumed that whole you might have multiple simultaneous connections, you'd always want messages to arrive in one of them, your 'current' one.
  413. ralphm (while)
  414. Ge0rG And thus "most avaliable non negative presence" was born.
  415. ralphm The assumption now is that you basically want chat-like messages to arrive on all devices, with history, and proper distributed read markers
  416. jonasw "and it was good" no wait
  417. ralphm So yeah priority is mostly useless now
  418. Kev I don't think the priority-based routing was actually a good idea, but I'm sure it seemed one at the time, a decade before that use case came about.
  419. ralphm I'm still not sure about aggregate availability / show presence.
  420. Kev In which way? I think that individual devices having a different status message is unhelpful for most use cases these days.
  421. ralphm I could imagine using priority for that exclusively
  422. Kev To the point that I'm sorely tempted we (non-formally) deprecate status messages, and just shove something in PEP.
  423. ralphm Sure, Slack has per account status and 'snooze'
  424. ralphm Making it explicit that way seems the way to go
  425. daniel has left
  426. Kev Aggregating status locally is easy enough, I think.
  427. Kev But messages are harder.
  428. Kev I don't think it's a hardship for a receiving client to see two auto-away, one available, so mark the contact as available.
  429. Kev (Although it's not how we'd design it if we were starting again)
  430. daniel > contracts shouldn't be able to choose what happens to my archive Kev: I'm not really sure how this would look like. Even if we change to a full jid / bare jid approach it's ultimately up to the sender to make that decision
  431. Ge0rG I'm also in favor of aggregate presence status, but we don't need to throw everything over for that
  432. Kev daniel: I'd like to make a fuller response Monday, I just noticed the PR and wanted to leave a holding message to stop it getting merged until I'm working again after the weekend.
  433. ralphm I think we should be precise and not talk about 'presence'
  434. Ge0rG ralphm: feel free to provide a better glossary
  435. ralphm Rather about availability-presence, user status and such
  436. Kev But, basically, telling an archive server that someone sending me a message gets to override the rules of my server policy has to be obeyed isn't helpful in most cases. I'm happy with (more loosely than you're doing) excluding groupchat from default access, but the <store/> thing needs more care.
  437. Kev More Monday :)
  438. ralphm Availability still has use cases, even beyond chat
  439. Kev Ge0rG: I would still like to work with you on XEPpifying these thoughts (although I'll do it on my own if you're still not keen).
  440. lovetox has joined
  441. ralphm Slack status is much like user mood and user activity conflated
  442. Ge0rG Kev: I'm not opposed, I just still think it's too early
  443. Kev ralphm: And I think more matches what the typical use case needs.
  444. ralphm I.e. you pick an emoji and a status message to go with it
  445. ralphm Totally
  446. Kev But Slack still does presence.
  447. Kev (availability)
  448. Ge0rG There is a good case for dnd at least
  449. Kev I think in XMPP we could easily codify something here that makes slackishness work, along with other use cases, without needing to throw baby out with the bathwater.
  450. ralphm But do note that Slack also has binary availability (green or dark icon) as well as snooze indicator. The latter is per account, and I assume the former is simply a logical or.
  451. Kev I think <status/> is going to be a victim in this.
  452. ralphm Indeed, as well as show
  453. Kev I think we keep show.
  454. Ge0rG But but but but I want custom text status, or at least Emoji
  455. Kev But I think we codify some rules of how to do a trinary logical or on it.
  456. ralphm Ge0rG: please read again
  457. Kev Ge0rG: Yes, but I don't think <status/> is fit for that per-account use. I think we PEP that.
  458. ralphm We'd move this to a PEP nice
  459. ralphm Node
  460. ralphm Like User Mood and User Activity XEPs
  461. Kev And probably replacing both, if we're honest.
  462. ralphm Sure
  463. Kev Well, or combining both.
  464. Ge0rG Kev: persistent or ephemeral pep?
  465. Kev If we changed User Mood into an emoji :D
  466. ralphm Without predefined items
  467. Kev Ge0rG: persistent.
  468. ralphm Even though they are extensible
  469. blabla has joined
  470. Ge0rG Kev: I think I still have some junk in my pep (different account) from a client that I tried some years ago
  471. Kev I've added to my list of things I need to cover in the xmpp2.0-not-called-xmpp2.0 Informational XEP.
  472. Kev My intention is to write a XEP summarising Ge0rG's slidedeck, together with our current best guess on how we'll approach solving it.
  473. Kev Mostly so that we have this tracked in some way that the XSF's process understands.
  474. Kev Right, I'm going back to hiding my XMPP and Mail clients again :)
  475. Kev o7
  476. ralphm I guess we can fill those summit days easily
  477. Valerian has joined
  478. efrit has joined
  479. Syndace has left
  480. Syndace has joined
  481. ralphm has joined
  482. sonny has joined
  483. Steve Kille has left
  484. marc has left
  485. sonny has left
  486. sonny has joined
  487. efrit has left
  488. ralphm has joined
  489. Kev has left
  490. vanitasvitae has left
  491. Valerian has left
  492. Zash has left
  493. lskdjf has left
  494. lskdjf has left
  495. lskdjf has left
  496. lskdjf has left
  497. uc has left
  498. uc has joined
  499. ralphm has joined
  500. la|r|ma has joined
  501. Arc has left
  502. Valerian has joined
  503. blabla has left
  504. Steve Kille has left
  505. lskdjf has joined
  506. lskdjf has left
  507. Alex has left
  508. lskdjf has left
  509. Guus has left
  510. uc has joined
  511. uc has joined
  512. Tobias has joined
  513. la|r|ma has left
  514. la|r|ma has joined
  515. Guus has left
  516. lskdjf has left
  517. jere has joined
  518. lskdjf has left
  519. lskdjf has left
  520. sonny has left
  521. sonny has joined
  522. SamWhited has left
  523. lskdjf has joined
  524. lskdjf has left
  525. lskdjf has left
  526. lskdjf has left
  527. ralphm has joined
  528. lskdjf has left
  529. lskdjf has left
  530. lskdjf has left
  531. lskdjf has left
  532. lskdjf has left
  533. lskdjf has left
  534. lskdjf has left
  535. lskdjf has left
  536. Steve Kille has left
  537. lskdjf has left
  538. jere has joined
  539. Tobias has joined
  540. la|r|ma has joined
  541. lskdjf has joined
  542. Tobias has joined
  543. nyco has left
  544. vanitasvitae has left
  545. nyco has joined
  546. ralphm has joined
  547. lskdjf has joined
  548. daniel has left
  549. Zash has joined
  550. ralphm has joined
  551. daniel has left
  552. Guus has left
  553. Steve Kille has left
  554. daniel has left
  555. mimi89999 has left
  556. uc has left
  557. Tobias has joined
  558. Guus has left
  559. tim@boese-ban.de has joined
  560. Valerian has left
  561. Tobias has joined
  562. Zash has left
  563. Zash has left
  564. SamWhited has left
  565. Tobias has joined
  566. jjrh has left
  567. Valerian has joined
  568. Guus has left
  569. jere has joined
  570. jere has joined
  571. Valerian has left
  572. lskdjf has left
  573. lskdjf has left
  574. Guus has left
  575. Valerian has joined
  576. Tobias has joined
  577. Steve Kille has left
  578. lskdjf has left
  579. lskdjf has left
  580. lskdjf has left
  581. lskdjf has left
  582. lskdjf has left
  583. Steve Kille has left
  584. lskdjf has left
  585. lskdjf has joined
  586. lskdjf has left
  587. lskdjf has joined
  588. tux has joined
  589. moparisthebest Does anyone use haproxy for xep368 or anything using alpn?
  590. lskdjf has left
  591. lskdjf has left
  592. lskdjf has left
  593. lskdjf has left
  594. lskdjf has left
  595. lskdjf has left
  596. lskdjf has left
  597. lskdjf has left
  598. lskdjf has left
  599. Steve Kille has left
  600. Zash has left
  601. lskdjf has left
  602. xram moparisthebest: https://blog.onefellow.com/post/76702632637/haproxy-and-ejabberd
  603. xram without alpn though
  604. lskdjf has joined
  605. Steve Kille has left
  606. lskdjf has left
  607. Steve Kille has left
  608. xram has left
  609. lskdjf has joined
  610. lskdjf has left
  611. lskdjf has left
  612. lskdjf has left
  613. lskdjf has left
  614. lskdjf has left
  615. lskdjf has left
  616. Steve Kille has left
  617. daniel has left
  618. lskdjf has left
  619. daniel has left
  620. lskdjf has left
  621. lskdjf has left
  622. Valerian has left
  623. Valerian has joined
  624. lskdjf has left
  625. Valerian has left
  626. moparisthebest Yea mainly wondering if it can multiplex on alpn without terminating TLS or not
  627. Guus has left
  628. moparisthebest Guy in conversations muc is trying to figure it out
  629. Steve Kille has left
  630. Steve Kille has left
  631. la|r|ma has joined
  632. zinid not sure what the problem is, there is tons of info in google
  633. zinid for example: https://www.haproxy.com/documentation/aloha/7-0/haproxy/tls/
  634. daniel has left
  635. lskdjf has left
  636. lskdjf has joined
  637. lskdjf has joined
  638. Valerian has joined
  639. Guus has left
  640. Tobias has joined
  641. lskdjf has joined
  642. moparisthebest That's about terminating TLS though, he got it working doing that https://pastebin.ca/3939980
  643. moparisthebest It's just not necessary
  644. Tobias has joined
  645. Kev has left
  646. daniel has left
  647. daniel has left
  648. lskdjf has left
  649. lskdjf has joined
  650. Guus has left
  651. Steve Kille has left
  652. SamWhited has left
  653. lskdjf has left
  654. lskdjf has left
  655. lskdjf has left
  656. lskdjf has left
  657. Guus has left
  658. lskdjf has left
  659. lskdjf has left
  660. jere has left
  661. jere has joined
  662. lskdjf has joined
  663. lskdjf has left
  664. lskdjf has left
  665. lskdjf has left
  666. lskdjf has left
  667. lskdjf has left
  668. lskdjf has left
  669. lskdjf has left
  670. lskdjf has left
  671. lskdjf has left
  672. lskdjf has left
  673. valo has joined
  674. valo has joined
  675. lskdjf has left
  676. lskdjf has left
  677. lskdjf has left
  678. lskdjf has left
  679. lskdjf has left
  680. Arc has joined
  681. lskdjf has joined
  682. lskdjf has joined
  683. lskdjf has left
  684. ralphm has joined
  685. lskdjf has left
  686. lskdjf has joined
  687. lskdjf has left
  688. lskdjf has left
  689. lskdjf has left
  690. lskdjf has left
  691. lskdjf has left
  692. lskdjf has left
  693. Guus has left
  694. lskdjf has left
  695. lskdjf has left
  696. lskdjf has left
  697. zinid has left
  698. lskdjf has joined
  699. daniel has left
  700. Guus has left
  701. ralphm has joined
  702. Valerian has left
  703. Valerian has joined
  704. jubalh has joined
  705. Holger has left
  706. Alex has joined
  707. sonny has joined
  708. jubalh has left
  709. daniel has left
  710. marc has left
  711. Holger has left
  712. lskdjf has joined
  713. lskdjf has joined
  714. daniel has left
  715. SamWhited has left
  716. uc has joined
  717. uc has joined
  718. Holger has left
  719. sonny has left
  720. uc has joined
  721. sonny has joined
  722. lskdjf has joined
  723. daniel has left
  724. Alex has left
  725. lskdjf has joined
  726. lskdjf has joined
  727. mimi89999 has left
  728. daniel has left
  729. Valerian has left
  730. jubalh has joined
  731. Valerian has joined
  732. Valerian has left
  733. Valerian has joined
  734. Valerian has left
  735. nyco has left
  736. nyco has joined
  737. lskdjf has joined
  738. Valerian has joined
  739. Valerian has left
  740. la|r|ma has left
  741. lskdjf has left
  742. Valerian has joined
  743. Valerian has left
  744. jere has joined
  745. jere has joined
  746. Valerian has joined
  747. ralphm has joined
  748. tux has joined
  749. lovetox has left
  750. bra has left
  751. la|r|ma has joined
  752. la|r|ma has joined
  753. daniel has left
  754. uc has joined
  755. Valerian has left
  756. Guus has left
  757. lumi has joined
  758. jubalh has left
  759. ralphm has joined
  760. daniel has left
  761. jubalh has joined
  762. daniel has left
  763. lskdjf has joined
  764. Guus has left
  765. uc has joined
  766. arc has left
  767. arc has joined
  768. daniel has left
  769. lskdjf has joined
  770. Arc has left
  771. lovetox has joined
  772. lskdjf has left
  773. arc has left
  774. arc has joined
  775. arc has left
  776. lskdjf has left
  777. uc has joined
  778. lskdjf has left
  779. arc has joined
  780. lskdjf has left
  781. lumi has joined
  782. goffi has left
  783. lskdjf has left
  784. lskdjf has left
  785. jubalh has left
  786. jubalh has joined
  787. jubalh has left
  788. jubalh has joined
  789. lskdjf has left
  790. lskdjf has left
  791. Arc has joined
  792. jubalh has left