XSF Discussion - 2018-03-20

  1. Ge0rG

    So Facebook is in the middle of a huge data protection scandal. Can we widely deploy XMPP now?

  2. flow


  3. Ge0rG

    Ah, still no web client.

  4. Ge0rG

    Yeah well, let's wait for the next scandal then

  5. Tobias

    let's wait for the Facebook Uber merger, then everything will be fine

  6. mrdoctorwho

    Uber has chat already, and you can view your driver's profile

  7. mrdoctorwho

    Not so far from FB

  8. moparisthebest

    uber did just directly kill their first person yesterday so

  9. Andrew Nenakhov

    Ge0rG, > Ah, still no web client. Your information is outdated )

  10. Andrew Nenakhov

    As for Uber killing person, from what I got about this incident, person got himself killed with Uber

  11. Ge0rG

    Andrew Nenakhov: tell me about an as-easy-as-slack xmpp client!

  12. Ge0rG

    I expected that.

  13. Andrew Nenakhov

    Ge0rG, Xabber, of course

  14. Ge0rG

    Andrew Nenakhov: does it already have Carbons by default?

  15. Ge0rG

    Can I self-host Xabber-Web? Is there Xabber-iOS?

  16. Andrew Nenakhov

    Ge0rG, of course it does, for more than a year. Of course you can host it.

  17. Andrew Nenakhov

    iOS version is coming. Currently it's still ugly (not Mohal or ChatSecure-level ugly, though) but it does work more or less ok.

  18. Andrew Nenakhov

    We plan to release it in late April if all goes well

  19. Ge0rG

    Andrew Nenakhov: that's great news! Will Xabber-Web work without xabber-websocket?

  20. Andrew Nenakhov

    Nope. But there is no workaround and if it's self hosted you can still run it on your own server

  21. Andrew Nenakhov

    It can in theory work with Bosh but result is shitty. Way too slow.

  22. daniel

    Andrew Nenakhov: why doesn't it use regular websockets though?

  23. daniel

    I thought xabber-websocket is just a tcp websocket proxy

  24. daniel

    For servers that don't have websockets

  25. Ge0rG

    Can I use wss://web.xabber.com/websocket to port-scan remote servers? :D

  26. Andrew Nenakhov

    Can't work without proxy for off-site domains

  27. Andrew Nenakhov

    Ge0rG, actually you can )

  28. Ge0rG

    Andrew Nenakhov: my next question would be "can I portscan redsolution DMZ", but it looks like a VPS / colo server :>

  29. Ge0rG

    > Group chats are not implemented yet. No xabber-web for me :(

  30. Andrew Nenakhov

    Xep-0045 is broken by design and we don't even want to waste time on it, sorry

  31. Ge0rG

    Andrew Nenakhov: there should be a prominent [+] button in the web UI

  32. Andrew Nenakhov

    There is ) or you want it even more prominent?

  33. Ge0rG

    Andrew Nenakhov: 0045 is fixable. Have you looked at MIX already?

  34. Ge0rG

    And I should be able to just start a chat with somebody by typing their JID into the "Search chats" / "Search contacts" box

  35. Ge0rG

    Andrew Nenakhov: the (+) button will add a contact or an account (the latter should be part of the preferences)

  36. Ge0rG

    Andrew Nenakhov: I'd like to talk to a JID without adding them first.

  37. Ge0rG

    Andrew Nenakhov: or maybe have an (+) when I stopped typing a JID

  38. Andrew Nenakhov

    No way, spammer!

  39. Ge0rG

    like Chrome's universal input box, you enter a string and the client figures out what you want

  40. Ge0rG

    Andrew Nenakhov: I hope you are kidding

  41. Andrew Nenakhov

    No subscription no talk. 😈

  42. Ge0rG

    Andrew Nenakhov: I hope you are kidding

  43. Ge0rG

    xabber-web will show and notify me of messages from foreigners, so why shouldn't it allow to start chats?

  44. Andrew Nenakhov

    There are reasons. Mainly because Xabber web is heavily archive centric

  45. Ge0rG

    Andrew Nenakhov: but it's got a nice clean UI and a good registration flow

  46. Ge0rG

    Andrew Nenakhov: and your MAM defaults to roster-only?

  47. Andrew Nenakhov

    And we can't gather messages from strangers with current mam

  48. Ge0rG

    Why not? You can just MAM everything?

  49. Andrew Nenakhov

    We can, but how exactly do we extract data from it after browser reload?

  50. Ge0rG

    Andrew Nenakhov: good point. You could query everything from last 1hr / 24hr / 14d...

  51. Andrew Nenakhov

    Too data expensive. We're working on server protocol to solve this problem.

  52. Ge0rG

    Andrew Nenakhov: something like "list of recent chat JIDs"?

  53. Andrew Nenakhov

    Of course. We call it list of recent conversations.

  54. Ge0rG

    Andrew Nenakhov: I'd love to see the XEP for that

  55. Andrew Nenakhov

    It will be, if it'll work well.

  56. daniel

    Fwiw other people are working on the same thing

  57. Andrew Nenakhov

    Ge0rG, MIX will never be in ejabberd so no reason to even look at that ) and no, 0045 is not fixable. If you want push notifications on mobile client , you need ad hoc rubber band aids, if you want to talk seamlessly from different clients you need aids like bookmarks. Better do a new proper group chat.

  58. daniel

    Under the name 'inbox'

  59. Ge0rG

    Andrew Nenakhov: I disagree. I'm fixing the little warts of 0045, one after the other.

  60. Kev

    Fix them all and put the enhancements in and eventually you'll have 369.

  61. Andrew Nenakhov

    It's beyond help in our opinion. :-/

  62. Ge0rG

    Kev: the enhancements that are only needed by a vocal special-case minority, and that complicate the protocol tremendously?

  63. Kev

    I mean mostly just putting pubsub nodes for extra data.

  64. Ge0rG

    Kev: IMVHO, we can rescue MIX by axing at least half of the XEP.

  65. Kev

    I'm potentially up for that.

  66. Maranda

    Chop chop

  67. Ge0rG

    people are making fun of us for that XEP.

  68. MattJ

    Doing so (if the right half is axed) then I'm potentially up for implementing it in Prosody again

  69. Kev

    I think very possibly the user server stuff goes away, for one thing. Waiting for thoughts from Dave and Matt on that.

  70. Ge0rG

    MattJ: the hard part will be getting consent on which the right parts are.

  71. Ge0rG

    Kev: that's not the part I wanted axed.

  72. Kev

    Which part do you want axed?

  73. Ge0rG

    I'd even argue that we can have userserver-side MUC persistence today, based on bookmarks and with zero protocol updates

  74. Maranda


  75. Ge0rG

    Kev: proxy JIDs would be the highest prio thing for me to get rid of.

  76. Andrew Nenakhov

    We'll implement good group chat to our liking, make it work on our server and 3 (6?) platforms and call it a day )

  77. Andrew Nenakhov

    Ge0rG, those bookmarks that are already proposed to be replaced? 😂

  78. Ge0rG

    Kev: I'm still opposed to roster integration of MIXes, but this is a minor one

  79. Ge0rG

    Andrew Nenakhov: it doesn't matter which bookmarks are used.

  80. MattJ

    Andrew Nenakhov, so interop is not a goal for you?

  81. Maranda

    So muc is being replaced with something with higher running complexity or that's gonna get "axed" right...?

  82. Ge0rG

    Kev: message retraction can be solved with LMC. Direct invitation needs to get half of the fields stripped, because security. current MAM use is a huge mess

  83. MattJ

    Maranda, theoretically MIX's foundations are simpler than MUC's, I believe

  84. Ge0rG

    MattJ: in practice, it inherits most of MUCs problems.

  85. Andrew Nenakhov

    Interop is definitely a goal. I'm just not a fan of making theory-based standards. One should be implemented first and work well. Then standard can be based on implementation.

  86. Maranda

    I love the *practically* more MattJ you know me 😘

  87. Ge0rG

    Kev: I think that's it, from a brief look through the MIX TOC

  88. Ge0rG

    Zash: IIRC you volunteered to implement a PoC server-side MUC idle client

  89. Ge0rG

    let's call it "MUC bouncer" ;)

  90. Andrew Nenakhov

    We do software, implement on Android, iOS, web, maybe even desktop, then publish docs.

  91. Maranda

    ... Because if we end with something that is O(N^2) on most things again we might as well stay with MUC. 😀

  92. Zash

    Ge0rG: not quite

  93. Kev

    We can't do pseudonymous rooms without something like proxy JIDs, though.

  94. Ge0rG

    Kev: Sam had a nice proposal of burner JIDs, which would be added into the routing mix

  95. Ge0rG

    Kev: so you register with a burner JID component and use that identity to join MUCs, MIXes etc.

  96. Ge0rG

    Kev: I'm sure that can be polished into a proper protocol with some amount of work, and it would remove the proxy JID stuff from MIX

  97. Ge0rG

    proxy JIDs are a pseudonymity emulation only anyway.

  98. Andrew Nenakhov

    Ejabberd developer said they won't implement MIX

  99. Kev

    I maintain that it's a Really Bad Idea to bake anonymous proxies in like that.

  100. Ge0rG

    Kev: to bake them into what exactly?

  101. Kev


  102. Andrew Nenakhov

    No support in ejabberd == XEP dead on arrival

  103. Ge0rG

    Kev: as opposed to special-case anon proxies in MIX?

  104. Kev


  105. Ge0rG

    Kev: I know well what happens if we provide anon proxies to the masses (see IBR bot spam), but what would be wrong with having a burner proxy attached as a component on a MIX service, with no external s2s?

  106. Ge0rG

    One could argue that such a proxy could enforce a given "burner" JID for a given source JID, so the mapping would be a constant 1:1

  107. Kev

    And the compexity ends up much greater like that than it is with MIX proxy JIDs.

  108. Ge0rG

    Kev: except that the complexity will be spread onto multiple components that can be debugged individually

  109. Kev

    I don't think that's true, you end up needing to break the abstractions, I think.

  110. Ge0rG

    Kev: I'd like to see proof of that.

  111. Kev

    Of all the bits of MUC that are hard to work with, I'm not convinced that there being proxy JIDs are them.

  112. Ge0rG

    Kev: I haven't even started addressing the hard bits from MUC yet. I'm only speaking of the new exciting MIX features

  113. ralphm

    Andrew Nenakhov: I think you are misinformed

  114. ralphm

    Andrew Nenakhov: there's been ongoing work for ejabberd on MIX for almost two years now

  115. Andrew Nenakhov

    ralphm, Evgeniy Khramtsov told me himself

  116. Andrew Nenakhov

    I'll ask him again, ok

  117. ralphm


  118. Holger

    ralphm: Yes this was during the early stages of MIX development.

  119. Holger

    I think Andrew is right that zinid isn't motivated to implement the current revision (nor am I).

  120. ralphm

    That's regrettable.

  121. Ge0rG

    Not at all, for a specification you need approximately a business day just to read and to make sense of.

  122. ralphm

    Holger: is that because of complexity, or because there's no (current) business justification for working on it?

  123. ralphm

    Ge0rG: fwiw, XEP-0060 is a lot bigger

  124. Ge0rG

    ralphm: luckily, nobody ever implemented all of 0060.

  125. ralphm

    This is false

  126. Ge0rG

    "no single party"?

  127. edhelas

    0060 is a specifc XEP, each time you look at it you find new features and things to implement

  128. Ge0rG

    MIX makes use of 0060, so you need that in addition to MIX.

  129. Ge0rG

    And then there is the publish-options security nightmare we had recently.

  130. flow

    A quick word count shows that xep60 is 1.7x the size of MIX, FWIW

  131. flow

    and both are not XEPs I would mention as good examples

  132. Ge0rG

    They are good examples for design by committee.

  133. flow

    which committee?

  134. Andrew Nenakhov

    Committee of people who wouldn't implement it in software

  135. Ge0rG

    flow: I assume this is a rhetorical question

  136. ralphm

    that's ridiculous, most of XEP-0060 was defined by just the three people on the author list

  137. Andrew Nenakhov

    Ge0rG, not everyone knows this ideom

  138. ralphm

    and for MIX, the people that wrote it are also implementing it

  139. flow

    ralphm, I doubt that

  140. flow

    uhh, implement*ing*

  141. edhelas

    it would be nice to have a propre IRL discussion about just Pubsub

  142. intosi smiles

  143. flow

    I read implemented

  144. edhelas

    have a state of the art, see what we understand, maybe with a hackaton to fix the things that we're talking about

  145. edhelas


  146. Holger

    ralphm: I can't really speak for zinid, but for him it might be a bit of both. As MIX development stalled they came up with their MUC/Sub thing as a temporary solution, and now that mostly does the trick for their customers.

  147. ralphm

    I'm sure there are issues, but the statement that it was design-by-committee and by non-implementors is just false.

  148. Holger

    ralphm: I wasn't involved with implementing the earlier draft, but according to zinid it was much easier to actually re-use PubSub code back then.

  149. moparisthebest

    are there problems with muc-sub ? like a reason it isn't a good replacement for MUC/MIX?

  150. Holger

    As far as I'm concerned it's just the sheer complexity which is demotivating.

  151. flow

    At it's core MIX isn't that complex

  152. flow

    It's just everything stuffed into the XEP, just like PubSub, that makes one wanna run awawy

  153. flow

    And it becomes hard and harder to distill the gist out of as longer as it stays that way. IIRC ppl attempted a few years back to modularize xep60/PubSub and that never got anywhere

  154. ralphm

    flow: that was just editorial, not actually changing anything in the protocol

  155. flow

    ralphm, I know

  156. flow

    but even that would improve the situation

  157. edhelas

    I'm ok to have a couple of days and do that with a bunch of persons

  158. ralphm

    flow: I still have the stacks intosi and I made a few summits ago

  159. edhelas

    0060 is the core of many many things that we are doing at the moment, from MIX, to PEP related XEP, MAM is linked to it

  160. flow

    IIRC Zash was running with scissors too

  161. Zash

    I helped

  162. intosi


  163. intosi

    As did Chris, by finding printers with enough reams of paper.

  164. Zash

    The threshold for resuming that seems high :/

  165. edhelas

    is it possible to just rewrite it ?

  166. edhelas

    starting from the bases and slowly adding back all the features that we had

  167. edhelas

    it's what I'm doing when I have to refactor code and it's a mess

  168. flow

    Maybe a good starting point would be to tag every xep60 section as mandatory-to-implement or optional in a wiki page and start from there

  169. flow

    edhelas: rewriting xep60 appears to be to drastic, inefficient and error prone, but maybe that's not what you had in mind?

  170. edhelas

    well not really

  171. edhelas

    I was saying to basically re-understand the substance of all the sections, maybe put that on a wiki, and rewrite properly those things once we figured out the whole schema

  172. manuel-rubio

    hey! I was checking MIX and I'm still checking it (there are still several typos) but I wanted to change the section 6.3, Ensuring Message Delivery to use "ping" (XEP-0199) instead of the "marker" tag (that's confusing me with markable from Chat Markers (XEP-0333), how can I propose it?

  173. edhelas

    but it would be more efficient to do that IRL, during a meetup, like a full day, 3 personnes with already some Pubsub background and a set of rules

  174. flow

    manuel-rubio, send a PR, but what's the motivation behind that change?

  175. ralphm

    edhelas: I think the split is already more or less clear, I'll see if I can pick that up again

  176. ralphm

    But I'm not sure if that is a blocker for building MIX

  177. flow

    ralphm, Is the split documented somehere?

  178. ralphm

    as I said, I have the stacks of paper here

  179. flow

    would be great if it where on some wiki page or such, so that more people could participate

  180. flow

    and contribute

  181. Ge0rG

    ralphm: my design-by-committee impression of MIX results from each involved party stuffing their favorite feature into the specification, and us ending up with a huge and complex piece of meta-protocol.

  182. ralphm

    from the top of my head it is roughly: basic stuff, managent/admin stuff, advanced use cases (publish options, content-based subs)

  183. moparisthebest

    ralphm, I don't know all the details, but wouldn't you agree it's pretty obvious MIX is too terrible to implement considering it's years old and has 0 implementations?

  184. moparisthebest

    the developers have spoken, you could say

  185. ralphm

    I don't know if there's a correlation, no

  186. moparisthebest

    it's really the only point that matters

  187. edhelas

    ralphm I'd be happy to have a session with you to work on that :D

  188. moparisthebest

    I mean you can figure out *why* no one is interested in implementing it and fix those things, or you can continue to say "it's not that bad" and convince no one

  189. edhelas

    maybe we can organise a Dutch Summit "Let's Make Pubsub Great Again"

  190. moparisthebest

    MPSGA doesn't quite roll off the tongue :P

  191. edhelas

    let's do some caps and tshirts for the next FOSDEM :p

  192. Andrew Nenakhov

    I'd rather support slogan "Let's Make XMPP Great Again". Just kidding, XMPP was never great. So real slogan should be "Let's Make XMPP Great For Once"

  193. Kev

    Except that there are implementations of MIX, BTW.

  194. SamWhited

    Kev: link?

  195. Kev

    Dave's got some, at least.

  196. Ge0rG

    If a tree falls in a forest, ...

  197. Tobias

    for Openfire

  198. SamWhited

    The only thing I see from searching is someone else asking for a link on a Jira issue last year sometime (either September or November, no idea what this date format is) with no response.

  199. moparisthebest

    Kev, iirc dave half implemented a super early version of MIX in openfire

  200. moparisthebest

    not sure I'd count that

  201. flow

    So no real implementations of MIX?

  202. SamWhited

    What happened with ejabberd's implementation? Someone earlier said they weren't going to implement it, but they did have one for a while IIRC?

  203. SamWhited

    If they gave up, that doesn't bode well for the people who keep saying it's not as complicated as it sounds.

  204. MattJ

    A bunch of people (including us [Prosody]) implemented the early stuff

  205. flow

    SamWhited, I think there never was code I would descripe as MIX implementation in ejabberd

  206. Ge0rG

    SamWhited: zinid (Evgeniy) said multiple times that there will be no MIX in ejabberd

  207. MattJ

    Possibly even before the XEP was submitted

  208. Holger

    flow: Well it was an earlier revision.

  209. SamWhited

    https://docs.ejabberd.im/tutorials/mix-010/ ?

  210. SamWhited

    What happened to that?

  211. Holger

    It's still around.

  212. SamWhited

    Holger: is it being developed, or was it abandoned?

  213. Holger


  214. flow

    Holger, was it tested against an client?

  215. MattJ

    The XEP just grew too big too fast, and with the current XEP I have no intention of implementing

  216. Holger

    SamWhited: It's not being developed. The XEP then went into a different direction.

  217. Holger

    flow: Is there a MIX client?

  218. MattJ

    But this conversation began from the suggestion that the situation may be improved

  219. SamWhited


  220. daniel

    That seems to be part of the problem. That mix is a moving target and people who initially implement something that was then changed completely are now afraid that the standard might change again

  221. SamWhited

    So that's multiple major servers that have old half implemented versions or say they have no intention of implementing. Sounds like we need a rethink.

  222. flow

    Holger, I'm not aware of one. I think the GSOC project last year tried to produce one but failed

  223. daniel

    At least that's in part what stops me from implementing it

  224. jonasw

    daniel, +1

  225. Holger

    daniel: I'm more afraid the standard won't change again :-)

  226. daniel


  227. jonasw

    it seems not too bad to me atm

  228. jonasw

    I don’t like the weird roster integration

  229. Ge0rG

    > daniel: I'm more afraid the standard won't change again :-) 🤣

  230. Kev

    jonasw: I think the XMPP2 rules may well do away with that.

  231. jonasw

    Kev, how that?

  232. Ge0rG

    Kev: so you want to bet XMPP2 on MIX?

  233. Kev

    Ge0rG: The opposite, I think.

  234. Kev

    Use the XMPP2 routing rules in MIX.

  235. moparisthebest

    it's also not just server devs, no client dev seems interested in it either

  236. moparisthebest

    currently it's a non-starter

  237. moparisthebest

    s/currently/past few years/

  238. Ge0rG

    Kev: so you are not talking of the weird roster integration?

  239. Kev

    I'm interested in it in all our clietns and our server, just haven't got to it yet.

  240. Kev

    Ge0rG: I think the roster integration can probably go away once routing rules change.

  241. Ge0rG

    I'm interested in fixing MUC

  242. Ge0rG

    Kev: please enighten me on how those interdepend

  243. jonasw

    moparisthebest, I *am* interested, but I don’t implement things without something to test against.

  244. Maranda

    > That seems to be part of the problem. That mix is a moving target and people who initially implement something that was then changed completely are now afraid that the standard might change again Or more likely that now it's ending being twice as cumbersome as muc is.

  245. Maranda

    Sounds more likely

  246. jonasw

    MUC is too simple though.

  247. jonasw

    see the mess Multi-Session Nicks is

  248. Ge0rG

    Maranda: and it also adds a bunch of legacy MUC issues

  249. jonasw

    that ain’t going to be fixed by putting some ducttape on MUC

  250. moparisthebest

    again are there problems with muc-sub ?

  251. Ge0rG

    jonasw: ITYM "underspecified"

  252. moparisthebest

    fully backwards compatible seems a huge giant plus

  253. jonasw

    moparisthebest, what’s muc-sub?

  254. daniel

    Maranda: well when I say _part of the problem_ I mean in fact _part_

  255. moparisthebest

    jonasw, something actually implemented https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/

  256. jonasw

    moparisthebest, is there a XEP?

  257. flow

    jonasw, something you can test against an implementation: https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/

  258. moparisthebest

    that is a xep, kinda? :)

  259. Holger

    jonasw: Basically 0045 plus PubSub notifications for offline members.

  260. edhelas

    daniel by the way, what are your plans regarding Bookmark support in Conversations, you want to move to a PEP storage ?

  261. jonasw

    moparisthebest, xeps are on xmpp.org/extensions/xep-%04d.xml ;-)

  262. flow

    jonasw, there is also muc-light

  263. moparisthebest

    jonasw, some are in inbox, some haven't made it there yet

  264. moparisthebest

    XSF kind of made clear 'MIX is the way, we don't care about what any actual developer thinks'

  265. moparisthebest

    which is why I assume it wasn't submitted

  266. jonasw

    where did the XSF make that clear?

  267. Ge0rG

    moparisthebest: XSF mainly consists of developers.

  268. flow

    a few years ago, when the demand for persistent groupchat rose, many MUC replacements appeared, unfortunately we only have one as experimental XEP

  269. SamWhited

    I was all for sticking with one way forward when mix was a bit smaller, but now it's gotten rather large, maybe muc-sub is worth a look again. It's been a while since I read it.

  270. jonasw

    I am pretty sure that if something which was much more trivial than MIX but fixes the issues of MUC was presented, it would gain massive adoption immediately.

  271. moparisthebest

    well there are developers that just write specs, then there are developers that write code

  272. Holger

    jonasw: Do you think it would be good to submit MUC/Sub? Wasn't MUC-Lite already rejected because we have MIX?

  273. jonasw

    Holger, I have no idea

  274. jonasw

    I also don’t know the history there

  275. SamWhited

    Oh, maybe I was thinking of MUC-Lite, I didn't realize these were two different things.

  276. moparisthebest

    also XSF has developer firmly entrenched in corporate proprietary servers that have odd use cases not suitable for everyone else

  277. moparisthebest

    which isn't a problem in itself

  278. moparisthebest

    but look at the XEPs around when MIX came in, a good number of them are virtually universally implemented at this point

  279. pep.

    edhelas, movim to PEP storage probably won't happen as long as access-model is not implemented/usable everywhere (from where I understand)

  280. moparisthebest

    that MIX has 0 implementations is telling

  281. edhelas

    pep. okay

  282. pep.

    I mean on servers

  283. Ge0rG

    SamWhited: I think we can sufficiently fix MUC with minor tweaks to the protocols and an optional "MUC bouncer" on the users' servers

  284. Maranda

    moparisthebest, I doubt it expecially when you have over half the server developers (me included) that do not intend implementing it in its current state, just saying.

  285. jonasw

    Ge0rG, how to fix the multi-session nick mess?

  286. SamWhited

    Ge0rG: I have a hard time beleiving that, but I'd love to see a plan outlined if you think it can be done.

  287. Ge0rG

    jonasw: it's not much of a mess

  288. jonasw


  289. Ge0rG

    jonasw: mainly a mess in some implementations

  290. jonasw

    Ge0rG, tell that to people trying to feature-discover through MSN.

  291. Ge0rG

    just because poezio doesn't get them right doesn't mean it can't be done with minimal effort

  292. Kev

    You *can* fix MUC, certainly, but it needs doing basically what MIX does, even if the way we currently describe MIX doesn't make it sound straightforward the core is.

  293. Ge0rG

    jonasw: feature discovery for messages is overrated

  294. pep.

    edhelas, I'm not talking for daniel, but that's what I gathered

  295. jonasw

    Ge0rG, we have many hacks and quirks in aioxmpp and jabbercat code which is solely due to the weirdness of MUCs handling of resources

  296. SamWhited

    It doesn't matter how straight forward the core is if no one else but a handful of people understand it. I'm not convince that statement is true, but if it is then someone who understands it needs to make it clear how simple it is.

  297. Maranda

    I think somehow I (partially) demessed that jonasw, Ge0rG at least appreciated the effort 😘

  298. jonasw

    Ge0rG, I like how MIX uses bare JIDs for identities and resources for sessions, unlike MUC. it simplifies a lot if we can just assume that.

  299. ralphm

    jonasw: indeed

  300. Kev

    SamWhited: Yes, this is true, and yes, we need to make it clear.

  301. ralphm

    jonasw: but that's a hard break from how MUC works

  302. jonasw

    ralphm, exactly

  303. jonasw

    which I think that you cannot simply fix MUC.

  304. Ge0rG

    jonasw: I'm using bare JIDs everywhere in my client except for MUC-PMs and it was straight forward to implement

  305. jonasw

    Ge0rG, you don’t have avatars in MUC, do you?

  306. ralphm

    jonasw: that's why I think MUC is not fixable without breaking compatibility

  307. moparisthebest

    jonasw, no one said MIX didn't have good ideas, just that together it's not good

  308. jonasw

    moparisthebest, I’m aware.

  309. flow

    jonasw> Ge0rG, I like how MIX uses bare JIDs for identities and resources for sessions, unlike MUC. it simplifies a lot if we can just assume that.

  310. Ge0rG

    jonasw: I don't have avatars. But I heard daniel fixed them recently?

  311. flow


  312. moparisthebest

    again are there specific problems with https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/ other than 'well it's not MIX' ?

  313. flow

    moparisthebest, isn't no answer an answer?

  314. jonasw

    Ge0rG, "fixed"?

  315. jonasw

    moparisthebest, my specific problem with that is that it’s not a XEP

  316. moparisthebest

    jonasw, how is that a problem

  317. flow

    but actually, I think there are 1-2 minor problems with MUC-sub

  318. Ge0rG

    jonasw: I haven't been watching avatars closely, sorry. Maybe I'm underestimating part of the problem space

  319. moparisthebest

    it's running code, that is documented, and can easily be submitted as a xep jonasw

  320. jonasw

    moparisthebest, I like to discourage large-scale deployment of things which aren’t XEPs.

  321. flow

    but nothing that would prevent me from seeing MUC-Sub as XEP

  322. jonasw

    moparisthebest, do it then! ;-)

  323. SamWhited

    If there are only 1-2 minor problems, that's pretty good, I really do need to read that again.

  324. Dave Cridland

    Catching up, but: a) I didn't implement MIX, Ash Ward did (mostly), and we concentrated on the async messaging cases we needed. But it *is* in use. Various things in later revisions diverged from what we did, however.

  325. ralphm

    moparisthebest: I didn't know of this specification until 30 min. ago, how can I have evaluated it against MIX? Was it submitted as an alternative to the Council?

  326. jonasw

    Ge0rG, everywhere but in MUC you can (and have to) associate avatars with bare JIDs. in MUCs, you have to use the full JIDs.

  327. Ge0rG

    jonasw: yes, as I said. You use bare JIDs everywhere but in MUCs.

  328. jonasw

    moparisthebest, it still doesn’t solve the full-jids-as-identities-issue which is my biggest beef with MUC tbh

  329. Dave Cridland

    b) I argued against "MUC-light" because it was neither MUC, nor particularly light.

  330. moparisthebest

    ralphm, iirc back then council made it clear they would consider nothing but MIX, who would have wasted their time submitting it?

  331. jonasw

    Ge0rG, earlier you said "MUC-PMs" ;-)

  332. Ge0rG

    jonasw: so you have an API get_foo_for_jid() and you can pass it a bare JID or a full JID of a MUC participant.

  333. Dave Cridland

    c) Without seeing MUC-Sub, I don't know how it would differ materially from MIX.

  334. Ge0rG

    jonasw: I probably meant "MUC participants"

  335. jonasw

    Ge0rG, depends. with avatar pushes in presence, the stuff handling the caches needs to be aware whether a JID is from a MUC or not. and this is where things get ugly.

  336. moparisthebest

    I also just learned about muc-sub within the last few weeks from someone in here

  337. Dave Cridland

    jonasw, FWIW, MIX uses bare jids too. But then doesn't use them for messages, which I never liked.

  338. Ge0rG

    jonasw: must inject more <x/>

  339. moparisthebest

    it just strikes me as 'good enough'

  340. jonasw

    Ge0rG, the <x/> is in there, but that’s breaking layers.

  341. ralphm

    moparisthebest: that's fine, but you are asking about an alternative that (almost) nobody has seen and why that is not better than MIX. I don't think it is reasonable to expect an answer during this discussion.

  342. moparisthebest

    Dave Cridland, did you see the link https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/

  343. Ge0rG

    Dave Cridland: I think MIX only used full JIDs for messages in the context of PMs and resource locking?

  344. moparisthebest

    sure ralphm , just pointing out there are alternatives that supposedly have running code

  345. moparisthebest

    and a (not-yet-submitted) spec

  346. SamWhited

    Reviewing them, muc-light is the one I've seen before and I didn't like it for similar reasons to Dave (also, at the time MIX still seemed like a viable way forward so it felt worth focusing on that and encouraging others to participate in that effort). MUC-sub I'll have to read because I don't think I have read this one and was just mixing (pardon the pun) it up with MUC-light.

  347. ralphm

    moparisthebest: but you don't have first hand experience with this muc-sub then?

  348. moparisthebest

    other than hearing about it in passing in here, and reading it, no

  349. Maranda

    I'm not sure I entirely get the *real* necessity of offline message deliveries if there's MAM as well.

  350. ralphm

    Maranda: indeed, the whole point of putting MAM behind all the things is that you don't have that anymore

  351. ralphm

    So, what are the specific issues with MIX that people trying to implemented are facing. So far I've heard 1) the complexity of the specification (as a piece of text, not necessarily the actual protocol), 2) the fact that there've been (big) changes.

  352. ralphm

    Did MIX really change that much since Feb 2017?

  353. Ge0rG

    Only in minor details

  354. Steve Kille

    ralphm: No. There was a lot of editorial stuff, but nothing really changed

  355. ralphm

    Right, so it is not really a moving target then

  356. Maranda

    Well at least it's reliable, offline delivers somehow not so much imho but that's debatable I guess.

  357. edhelas

    when I'm reading MIX, I have the feeling that we'll have a Pubsub syndrom in it

  358. edhelas

    I mean

  359. edhelas

    6.1.15 Telling another User about a Channel

  360. edhelas

    this whole piece can be a separate XEP

  361. Ge0rG

    edhelas: that's a rather small piece.

  362. edhelas

    yup, but still

  363. Maranda thinks he mentioned "running complexity"

  364. Ge0rG

    Maranda: can you point out specific cases of O(too much)?

  365. ralphm

    edhelas: huh? 6.1.15 is not using PubSub at all and points to a separate XEP?

  366. Ge0rG

    I think that using MAM both on the MIX and on the private account is a huge mess in the protocol

  367. Ge0rG

    "6.5.4 Converting a 1:1 Conversation to a Channel" is a huge security nightmare with questionable benefit

  368. Kev

    What's the mess protocol-wise?

  369. Kev

    (With 313)

  370. jonasw

    ralphm, (1) there’s on complete-ish server implementation I could test against (I’m a client developer. I also have limited time, otherwise I’d make one myself). (2) s2s failures (last time I checked) feld underappreciated in the spec, leading to possible desync between the MIX service and the users archive. skipping the archiving step at the users server would eliminate that risk and also simplify things. (3) The roster integration feels extremely weird. I’d prefer a different mechanism (specialized virtual PEP node for example).

  371. Ge0rG

    Kev: the fact that you have to query the data from different entities, depending on some (internal?) state

  372. ralphm

    Ge0rG: in terms of storage, for large rooms, having to MAM store room content 'user-side' seems pretty terrible.

  373. jonasw

    (ralphm, I think edhelas meant "PubSub syndrome" as in "one huge spec nobody can implement completely")

  374. Kev

    Ge0rG: That goes away with MIX and XMPP2, though.

  375. Kev

    For messages you just query your own.

  376. Ge0rG

    ralphm: so the solution is to store it in user's MAM as well as the MIX' MAM?

  377. moparisthebest

    no muc compatibility and requiring support on the user's server also seem to be non-starters

  378. edhelas

    jonasw exactly :)

  379. edhelas

    as a developper, is simpler to follow small specification, then you can mark that "done"

  380. edhelas

    so I implemented MIX-Core, now let's move to the MIX-Invitation XEP

  381. Kev

    Can't disagree with that, 369 as a spec is too long.

  382. ralphm

    Ge0rG: It seems perfectly normal to me to store one-to-one chats in the respective MAM archives of the two participants, and group chat history in a room-bound MAM archive, yes.

  383. ralphm

    moparisthebest: there are ways to provide an XEP-0045 layer on top of a MIX backend, of course with limited functionality.

  384. Ge0rG

    ralphm: yes, except that's not how MIX is defined.

  385. Ge0rG

    ralphm: > MIX messages are archived by both the MIX channel and the user's server, so that clients can generally use their local MAM archiver.

  386. Ge0rG

    > All MIX messages received by the MIX participant's server for a participant MUST be stored using MAM in the participant's archive.

  387. Ge0rG

    And then we have the issue of the user-proxy and the MIX getting desynced due to s2s issues

  388. Ge0rG

    Which we know never happens in MUCs

  389. ralphm

    Ge0rG: on MAM archives, I didn't remember those parts, and that's surely a choice that could be debated. I'm not sure why that choice was made. Maybe Steve Kille can comment on that

  390. Ge0rG

    Maranda: regarding runtime complexity: the user server is essentially an always-on proxy for all MIXes a user enters, for enternity. So if a user abandons their account, the server will still be receiving all their MIX traffic

  391. ralphm

    what? why?

  392. Maranda

    Ge0rG, I might fail to get the point glancing the current XEP but if the problem of muc is basically broadcasts I don't entirely see where MIX is solving it, splitting it..? 🤨 Well.

  393. Ge0rG

    Maranda: sorry, what context are you in right now?

  394. Maranda

    The same running complexity

  395. Ge0rG

    Maranda: I think we agree that MIX is not less complex than MUC in that regard?

  396. Maranda is multi-tasking atm.

  397. Ge0rG

    I should be single-tasking my work now.

  398. Holger

    > <Maranda> I'm not sure I entirely get the *real* necessity of offline message deliveries if there's MAM as well. The most important reason in practce is push notifications. My impression was that MUC being presence-based was the main driving force to come up with a replacement.

  399. ralphm

    Ge0rG: I don't get the 'for eternity' part. You mean that if a user never logs into his account anymore, the server would still get the room's notifications? This also goes for regular pubsub, and I don't see how that's a failure of MIX per se. I'm sure that server implementation need some kind of resource management in such cases anyway.

  400. Kev

    That and the broken proxyJIDding.

  401. Ge0rG

    ralphm: yes, except that typical pubsub has different traffic patterns compared to a large chatroom

  402. Ge0rG

    Holger: that problem can be solved by implementing a "MUC bouncer" on the user's server.

  403. ralphm

    Ge0rG: a mix bouncer is exactly what the PAM dependency in MIX does

  404. ralphm

    (unless that was your point, in which case never mind)

  405. Ge0rG

    ralphm: I know. But for MIX, you need to implement it on the client, on the server and on the MIX service. A "MUC bouncer" can be quietly implemented as part of the server without touching any protocol.

  406. ralphm

    Ge0rG: interesting, that would have the same impact on abandoned user accounts, though

  407. Ge0rG

    ralphm: indeed.

  408. Kev

    I think PAM becomes an optional dependency now, though, for MIX.

  409. ralphm

    a MUC bouncer is basically what IRC does, for MIX it is part of the package and considered a feature. Is your point that this MIX too complex?

  410. ralphm

    Kev: ah, can you expand on that?

  411. Kev

    And yes, we can make it transparent.

  412. Ge0rG

    ralphm: my point is that we don't need MIX as a solution to _that_ problem.

  413. Kev

    ralphm: If we change routing rules as $SUMMIT, we get bare-JID routing for MIXs, and we don't need the repeater in the user's server.

  414. Steve Kille

    ralphm: the MAM choice you referenced me on makes sense to me. Kev is probably the best person to explain

  415. ralphm

    Kev: but it would still require server's to implement /that/, so how transparent is that? On the whole, of course, I think it is a good idea.

  416. Kev

    Which 'that'?

  417. Kev

    The XMPP 2 routing rules? Yes, I think we need those, but we need those anyway.

  418. Ge0rG

    Kev: I'm pretty sure we'll run into interesting issues when attempting to route 'groupchat' messages to bare JIDs

  419. ralphm

    Kev: well, Ge0rG said that for doing MIX with PAM, you need the client, its server, and the MIX server to implement that. For the routing thing, you need both servers to be support that, no?

  420. ralphm

    Ge0rG: why? a server that doesn't support this responds with service-unavailable?

  421. ralphm

    (RFC 6121, section

  422. Ge0rG

    ralphm: I can imagine this not to be the desired outcome for a MIX participant.

  423. ralphm

    Ge0rG: so that's why Kev said that indeed the server of the MIX participant needs to support the new routing

  424. Ge0rG

    ralphm: "the new routing" never was about type=groupchat, so Kev must be meaning some newer-than-new routing that I know nothing about.

  425. Ge0rG

    So I'm not yet convinced that XMPP2 routing rules solve the MIX routing problem.

  426. Kev

    Ge0rG: You might not have intended it to cover gc, but I do.

  427. Zash

    Ge0rG: FWIW, what I already did was to write a thing that made the account join MUCs instead, while pretending to clients that nothing changed.

  428. Ge0rG

    Kev: that's a noble goal. Do you have any documentation on the _how_?

  429. Ge0rG

    Zash: that's exactly what I was talking about. A MUC bouncer of sors

  430. Ge0rG


  431. Zash


  432. Ge0rG

    Zash: how does "the account join MUC" work specifically? Are you using a fake client resource for that?

  433. Ge0rG

    Zash: did you encounter any unexpected things? Maybe we should promote that as a server feature?

  434. Zash

    Ge0rG: I think I encountered weirdness but I don't remember exactly

  435. Ge0rG

    Zash: I'm interested in repeating that experiment

  436. Ge0rG

    And while we are speaking of experiments...

  437. Ge0rG

    Maranda: do you happen to have new numbers on the GC1 usage?

  438. Maranda

    Hm not really.

  439. Ge0rG

    Maranda: what about a formal statement about the last numbers you gathered, e.g. on standards@? I'd like to use that as evidence that we can get rid of GC1 now.

  440. Maranda

    Ge0rG, if I had any last numbers gathered I would give out those, but beside the scarce muc usage on my server, looking at the clients using my server, I can sort of safely assume that as long as Pidgin doesn't still use it (I have no idea) there's no client using GC1.0

  441. Ge0rG

    Ah, I wish I had a prosody module logging that.

  442. Zash

    One that isn't mod_muc itself and that works with 0.10?

  443. Ge0rG

    Zash: 0.10 mod_muc would be alright with me.

  444. jonasw

    Ge0rG, if the archives were solely at the MIX service, the users server wouldn’t need to receive or process them, right?

  445. jonasw


  446. jonasw

    wtf poezio

  447. Ge0rG

    jonasw: yes

  448. Ge0rG

    jonasw: except the server would need to tell the MIX when to start and stop sending "live" traffic

  449. jonasw

    Ge0rG, BIND2 between server and MIX!

  450. Maranda

    Ge0rG, just making a fast census, the majority looks to be running Pidgin, the Mac users look to be running Adium few are using iMessage/iChat, some others Trillian, Telepathy... oh one is running Bruno :P

  451. Maranda

    and most used mobile looks to be Xabber, Conversations on second.

  452. Ge0rG

    Nobody is using yaxim 😢

  453. Maranda

    Ge0rG, nope one is using Bruno though :P

  454. Ge0rG

    Maranda: yeah, glad to hear that.

  455. Maranda

    which isn't responding to an IQ btw 🤔

  456. Ge0rG

    Maranda: what kind of IQ?

  457. Maranda


  458. Ge0rG

    Hm. Must be a very old version then. Or maybe the one with the bug where it dropped IQs because DoS

  459. Ge0rG

    But still very old

  460. Dave Cridland

    So. Yes, I did see muc-sub ages ago, and it's basically a hybrid of MIX and MUC.

  461. Dave Cridland

    And I do really hate wrapping messages in pubsub events and sending those as messages. Feels desperately inefficient.

  462. jonasw

    if we’re substantially changing MUC, it’d be great to revamp how JIDs work in MUCs, and that’s essentially the proxy JID concept of MIX. which everyone seems to hate.

  463. moparisthebest

    anyone know of a bot that integrates muc with jira ?

  464. Ge0rG


  465. jonasw

    Ge0rG, you know the answer ;-)

  466. moparisthebest

    well, kinda jira for tickets and such

  467. Ge0rG

    jonasw: yes, two bots. one to integrate git with pubsub and another one to integrate pubsub with muc

  468. Zash

    dvcs over pubsub!

  469. Maranda

    Ge0rG, be happy: [18:25:32] ‎Echo1‎: There was an error requesting ***@lightwitch.org/Bruno.554C7F0C's version: recipient-unavailable

  470. Maranda

    just dead session :P

  471. Ge0rG


  472. Ge0rG

    Zash: so what about GC1 logging in mod_muc?

  473. Zash

    Ge0rG: I started on a module ... twice

  474. jonasw

    Ge0rG, just hack it into muc.lib.lua. it’ll probably one line.

  475. Holger

    jonasw: Is there any reasoning behind the proxy JID concept besides hiding the real JID?

  476. Maranda

    Hmm eww

  477. Maranda

    why? mod_muc hooks at -1 anyways

  478. jonasw

    Holger, from which jid would one be receiving messages within the MIX otherwise?

  479. jonasw

    (and possibly presence)

  480. Maranda

    just make a 4 lines module and you're set

  481. Maranda

    (or less)

  482. Ge0rG

    Maranda: please make a 4 lines module

  483. Ge0rG

    jonasw: it's one line, but the challenge is in knowing where to put that line

  484. Zash

    oh, there is one

  485. Ge0rG

    ,oO( https://colterreed.com/the-parable-of-the-two-dollar-chalk-mark/ )

  486. Zash


  487. Zash

    Ge0rG: ^

  488. Maranda

    Ge0rG, hook to presence/bare?

  489. Zash

    I guess you can s/module:/origin./

  490. Ge0rG

    Zash: can have print of the resource string, and version-iq the client?

  491. Ge0rG

    module:log("info", "GC 1.0 join: {muc} {full-client-JID} {client version}") please :)

  492. Holger

    jonasw: Dunno, maybe the MIX service JID. But why do you need any sort of JID mapping if not for anonymization?

  493. Zash

    Ge0rG: You can do it, I believe in you

  494. Ge0rG

    Zash: I don't know where to put the chalk mark.

  495. Zash

    copy stuff from https://modules.prosody.im/mod_query_client_ver.html

  496. Ge0rG

    1. Copy random stuff from different modules 2. Deploy in production 3. ??? 4. Crashit

  497. Holger

    jonasw: The XEP text also makes it very obvious that this is the point, no? Plus all the JID visibility foo?

  498. Ge0rG

    Holger: I think the main reason for having proxy JIDs was indeed to make pseudonymous usage possible

  499. Ge0rG

    But when viewed from a message routing point of view, we probably need proxy JIDs to associate incoming messages to a MIX in some way.

  500. Ge0rG

    Or we need to wrap messages, like <message from=MIX><forwarded><message from=participant///>

  501. Holger

    Well the service could obviously just include some tag with the real JID no?

  502. Holger

    Like 0045 for non-anon rooms ...

  503. Ge0rG

    Holger: what would be the from-JID?

  504. Holger

    As I said my spontaneous response would be the groupchat service. But it's not like I thought about this. I just asked why we need a JID mapping.

  505. Ge0rG


  506. edhelas

    5) Adopt Proposal "Bookmarks 2 (This Time it's Serious)"

  507. edhelas

    it's planning to stay titled like that :D ?

  508. Zash

    I think we should put Dave in charge of naming all the things

  509. Ge0rG

    Zash: that position deserves a better name

  510. moparisthebest

    Ge0rG, clearly Dave should name the position

  511. Ge0rG

    moparisthebest: I think that naming your own position is a Segregation of Duties violation

  512. Zash

    Ge0rG: https://q.zash.se/9b36a85d05a9.txt (also some fixes highlighted by static checks)

  513. Zash

    Not actually tested

  514. Zash

    No warranty etc

  515. edhelas

    regarding Bookmark 2 do you think it's fine to put muc JID in the nodeid of the Pubsub item ?

  516. edhelas

    that is linked with the discussion we had about the format and limitation of those ids

  517. Ge0rG

    Zash: awww... I kind of hoped to have the version reply inline. Will loading this on my MUC component allow me to grep version responses for the MUC JID in some way?

  518. Zash

    Ge0rG: Prosody doesn't have any internal IQ tracking framework, so it gets a bit messier to do like that than what I'm willing to do while being this tired.

  519. Ge0rG

    Zash: alright, thanks. That's good enough, as I don't have any other kind of version IQ inducer running

  520. Zash

    Could encode stuff into the resource.. but uh

  521. Ge0rG

    Zash: nah, better not to.

  522. Ge0rG

    Zash: it's great as it is now.

  523. Ge0rG

    Zash: will it always log with <modulename> in the log line?

  524. Zash

    Ge0rG: All module:log() lines do, yes

  525. Ge0rG

    Zash: yay. Now all I need to do is to provoke a log manually.

  526. Ge0rG

    /rawxml <presence to="yaxim@chat.yax.im/Ge0rG" />

  527. Ge0rG

    nothing happens.

  528. Ge0rG

    Do I need to load it on the main domain instead of the MUC?

  529. Zash

    Supposed to be on the MUC

  530. Zash


  531. Zash


  532. Ge0rG

    heh, I wondered about that too

  533. Ge0rG

    Hm. Still nothing

  534. Zash

    Are you joined there already?

  535. Ge0rG


  536. Zash

    So it'll go to "normal presence update"

  537. Ge0rG

    Ah, ok.

  538. Ge0rG

    Mar 20 19:08:02 chat.yax.im:gc_log info GC 1.0 join from georg@yax.im/poezio

  539. Ge0rG


  540. Ge0rG

    Zash: thanks very much. I'll collect datas now.

  541. Ge0rG

    But no version followup there.

  542. Maranda


  543. Maranda


  544. Maranda


  545. Maranda got beaten to it, but you'd need to change it slightly anyways

  546. Maranda


  547. jonasw

    Ge0rG, Zash, it would be useful to know if the client was joined before and got removed with an error presence.

  548. Ge0rG

    was joined before using MUC protocol.

  549. Ge0rG

    Tracking hell

  550. Ge0rG

    I'm out for today. Let's hope it won't crash yax.im overnight

  551. Ge0rG

    Thanks everyone

  552. Maranda

    and woops typo but it looks to be working, https://muc.metronome.im:5280/pastebin/d84f1589-1920-4e48-8f47-b09e6fbe0ec4

  553. Maranda

    and woops typo but it looks to be working, https://muc.metronome.im:5280/pastebin/918d0c29-6e42-4c32-8c72-18fd75b860c7

  554. Ge0rG

    Was that last message correction without last message correction?

  555. Maranda

    Ge0rG, apparently... I corrected using Gajim, but Gajim didn't use Message correction?

  556. Maranda


  557. Maranda


  558. Maranda

    Ge0rG, no clue what I did there

  559. Ge0rG

    Maranda: this time it worked. Did you rejoin in between?

  560. lovetox

    i fixed a muc correction bug yesterday

  561. lovetox

    so .. this can happen from time to time

  562. Maranda

    Ge0rG, hmm no I don't think I did.

  563. Maranda

    lovetox, hmm 1.0?

  564. Maranda

    that's what I'm using

  565. lovetox

    yes it has that bug

  566. lovetox

    basically you have to be really fast with correction

  567. lovetox

    if any message in any other muc arrives it wont work anymore ^^

  568. Ge0rG

    Is this the week of major client releases? Gajim 1, Conversations 2, ???, Swift 4

  569. moparisthebest

    so the same as the https://en.wikipedia.org/wiki/Therac-25 bug ?

  570. moparisthebest

    except way less deadly

  571. Ge0rG

    lovetox: tell me about race conditions

  572. Maranda

    lovetox, oh, well I'm a turtle *known "bug"* :P

  573. Maranda saves speed for olympic lifts ™

  574. Maranda

    hehe brb.

  575. daniel

    Ge0rG: does your plan to improve muc also involve a rule that servers should force all connected clients to have the same nick?

  576. daniel

    Ie either first joined client gets force renamed to the nick the second client uses or vice versa

  577. daniel

    (somewhat re to what you wrote about bookmarks 2)

  578. daniel

    Inb4 but muh pidgin can't handle forced renames

  579. Ge0rG

    daniel: I don't see how pidgin is in a position to block progress of XMPP

  580. Ge0rG

    daniel: but to answer your question: no, I don't think we need to *force* all clients to the same nickname. But it would make sense to keep that the default

  581. daniel

    Tell that to the clients not implemting omemo. Lol

  582. Ge0rG

    daniel: because I'm sure joining the same MUC with two different nicknames at the same time is a use case needed by less than 0.1% of XMPP users

  583. Ge0rG

    daniel: as opposed to you, I don't see OMEMO as an integral part of the XMPP future

  584. daniel

    Ge0rG: well it wouldn't be the first time backward compat is raised as an argument not to do something

  585. Ge0rG

    daniel: with the two of us on Council, we can get rid of GC1, and then of pidgin

  586. daniel

    Wait council can get rid of pidgin?

  587. daniel

    Why haven't we done this before?

  588. Ge0rG

    daniel: I'll propose it as AOB tomorrow

  589. SamWhited

    I didn't know we had unilateral power over client devs, we should have been using this for blackmail ages ago.

  590. Ge0rG

    SamWhited: I was told we can vote on everything.

  591. jonasw

    Ceterum Censeo Pidgin Delendam Esse.

  592. daniel

    Ge0rG: well an opt out / opt in to server please rename me to what ever you think is right might be a way not to break pidgin

  593. daniel

    Aehm at least the opt in part

  594. Ge0rG

    daniel: i think we are having a misunderstanding. I'm speaking of the clients synchronizing the nickname to use, not about server side enforcing.

  595. Maranda

    Apparently killing Pidgin means killing a large portion of XMPP if my server numbers are any exportable 😆

  596. Maranda

    Art thou up for such perillous, murderous task?

  597. Zash

    What about crowdfunded maintenance?

  598. daniel

    Ge0rG: I'll summarize that as no such plans then

  599. moparisthebest

    this is a good argument for omemo/xmpp https://www.theverge.com/2018/3/20/17142482/russia-orders-telegram-hand-over-user-encryption-keys

  600. Andrew Nenakhov

    I can attest that 95% or more of OTR users in Russia are junkies.

  601. Andrew Nenakhov

    Also, Telegram is putting a show for masses, there is substantial evidence that it is already controlled by FSB

  602. moparisthebest

    wait how do you know they are junkies?

  603. Andrew Nenakhov

    I have access to Xabber support mailbox

  604. moparisthebest

    oh, fair :)

  605. moparisthebest

    that just means 95% of OTR users that ask for support are junkies though right?

  606. moparisthebest

    maybe it works great for non-junkies hehe :)

  607. Andrew Nenakhov

    Our app is defacto standard in their circles, they even write on websites 'sales support in Xabber'

  608. Andrew Nenakhov

    moparisthebest, I think 95% of e2ee users are criminals (junkies and drug/arms/etc sellers), and 5% crypto nerds )

  609. Andrew Nenakhov

    Cryptonerds never ask for tech support though

  610. Andrew Nenakhov

    They figure it out themselves and know why they use xmpp. But junkies... "i entered my Gmail address into Xmpp id field and it doesn't connect!".

  611. pep.

    Well you have to start somewhere right, first users that see value in the market, and then conquer the world

  612. moparisthebest

    well also OTR is terrible for usability, OMEMO fixes most of that

  613. moparisthebest

    my mom uses OMEMO messaging me without problems, she would have just used the default though if I didn't set it up for her

  614. Andrew Nenakhov

    I personally don't see any value in encryption, especially when running my own server. The only one e2ee is protecting from is server operator, and if that's mine... Why bother? Also it makes seamless syncing more difficult across devices and requires transmitting WAY more data

  615. Maranda

    and then are you certain it really is...?

  616. Maranda


  617. moparisthebest

    Andrew Nenakhov: servers never get hacked or misconfigured?

  618. moparisthebest

    I run my own too and haven't made those mistakes yet, but I'm not perfect

  619. Andrew Nenakhov

    Hacking a diligently configured server is not an easy thing to do. And it is not really linked to Telegram situation. Russian government wants direct access to user chat history that it can use without warrant or court decision

  620. Andrew Nenakhov

    In other news. In unexpected turn of events, making an XMPP client for iOS that works well we'll have to implement VoIP 😁

  621. Andrew Nenakhov

    *to make an , typo

  622. Holger

    Andrew Nenakhov: Yeah. The alternative is sending the body via APNS or generating ugly "New Message!" notifications.

  623. Andrew Nenakhov

    Ugly. Btw telegram sends all msg body in Alert-type msg, perfectly open, over APNS

  624. Holger

    Ah I was wondering how the commercial things do it.

  625. Andrew Nenakhov

    Currently we use non-voip push notifications of 'content-available' type, and it even kinda works...

  626. Holger

    But those are unreliable, right?

  627. Holger

    I.e. heavily rate-limited by Apple.

  628. Andrew Nenakhov

    Yes, but it looks to be tricky. Our developer sees almost perfect work on his test devices, but when we roll out build on test devices to managers, etc in company, it works much worse. As if iOS gives more priority to often used apps

  629. Andrew Nenakhov

    *this theory is not yet confirmed

  630. Andrew Nenakhov

    Also, when you read articles titled 'force-closing apps does not make your iPhone last longer, stop doing that', know it's a lie.

  631. Holger

    Yes it's my impression as well that the behavior is very different for different users. I didn't come up with a theory yet though, seemed totally non-deterministic to me.

  632. Andrew Nenakhov

    Content-available type notifications ARE NOT delivered to force-closed apps (swiped away ) at all

  633. Holger


  634. Andrew Nenakhov

    And not delivered after device restart until first launch, too.

  635. Andrew Nenakhov

    VoIP pushes, on the contrary, work very reliable.

  636. Andrew Nenakhov

    Force-close, restart - it works all the time.

  637. Holger

    Yup ...

  638. Maranda

    of course I vaguely recall VoIP apps getting treated differently even for what regards background running sockets.

  639. Maranda

    (and that was ages ago)

  640. Holger

    Maranda: Yes, that's going away though.

  641. Holger

    Maranda: VoIP apps are supposed to rely on push notifications now.

  642. Andrew Nenakhov

    APNS rules changed a while ago. In 2014 you could have a decent background updates without VoIP.

  643. Andrew Nenakhov

    We did an xmpp-based app for some guys back then, pushes worked well without additional hassle.

  644. Maranda

    I swear I can't express how much mobile OSes that do these stupid things with app tombstoning and background connections limit impositions annoy me.

  645. Maranda

    (and neither I get how can people spend 1400 eurs for a device that doesn't let you do what you want to with *your friggin battery*)

  646. Andrew Nenakhov

    Maranda, it'll get worse. I think Google will be locking developers into their ecosystem even more, displacing natural device capabilities with proprietary centralized FCM APIs.

  647. Maranda

    *le sigh*

  648. Andrew Nenakhov

    Google's and Apple's tyranny will be much more harsh one of Microsoft.

  649. Andrew Nenakhov

    I know a guy who makes a chat app based entirely on FCM. Just pushes and Google's cloud storage. Supaeasy

  650. fippo

    somehow this reminds me of the scene from lord of the rings where frodo offers the ring to galadriel...