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