XSF Discussion - 2018-05-29


  1. Zash

    ... but?

  2. Ge0rG

    Nobody does it. Maybe most client developers don't care about UX, nor about corporate use cases

  3. jonasw

    I feel that org setup is more of a server side thing?

  4. Ge0rG

    Server developers don't care about corporate either.

  5. jonasw

    I think the ignite folks do

  6. Ge0rG

    But that doesn't matter because the client UX sucks

  7. jonasw

    reminds me to make things even harder for clients by specifying the IBR flow for ToS

  8. jonasw

    even though I’m inclined to simply say "ToS setups where consent is required before signing up are not supported by this XEP, but may be handled by a future specification"

  9. Zash

    "use a web form or something"

  10. Ge0rG

    jonasw: so what you are trying to invent has no value over web forms but compatibility issues?

  11. Zash

    As opposed to everything else

  12. jonasw

    Ge0rG, it has; for GDPR, you don’t need consent anyways :)

  13. jonasw

    consent-requiring services will need that, but that’s #notmydepartment right now

  14. jonasw

    (but the spec can be extended to support that, so that’s good)

  15. jonasw

    Kev, MattJ, can some of you help me with an issue on jabber.org?

  16. jonasw

    Kev, MattJ, can some of you help me with an issue on jabber.org (the xmpp service)?

  17. MattJ

    Not sure if I'll be able, but shall if I can - what's up?

  18. jonasw

    there’s a room with an invalid JID on conference.jabber.org: @conference.jabber.org (yes, with empty node part)

  19. Seve/SouL

    I think Anu touches an interesting point and I have to agree with him on the specific idea he mentioned. Discord, for instance, does a very similar thing. Where you create a 'server' (I think they call it that way) and you can create as many as MUCs you want under that 'server'. Do we have a way in XMPP to do this? Like a top level node where you add MUCs under it? Maybe with MIX this is possible?

  20. jonasw

    Seve/SouL, apt install prosody, echo 'Component "sub.domain.example" "muc"' >> /etc/prosody/prosody.cfg.lua ?

  21. jonasw

    it would be great if that room could be nuked, MattJ

  22. Ge0rG

    jonasw: don't forget prosody-modules and two days of surfing the web to find out which versions of which modules are needed

  23. jonasw

    Ge0rG, MUC is luckily built-in :)

  24. Ge0rG

    Seve/SouL: I've argued for a long time that we need a two-click server deployment that integrates with LDAP, has all the nice modules... and a usable web client

  25. jonasw

    Ge0rG, do that!

  26. jonasw

    don’t argue, make it

  27. jonasw

    that being said, I think I mentioned that Guus is doing things in that direction. not only with a web client, but with WebRTC conference things

  28. Seve/SouL

    jonasw, haha, no no. I mean, unless you want to have this component for every user x) They call it a server but it's just like the root. Let's say we join Discord. I create a 'server' called XSF. And under it, I create offtopic, board, council, etc.. and everybody that joins the XSF 'server' can check the list of MUCs I've created for the XSF.

  29. jonasw

    but nobody is looking in that direction for some reasn.

  30. Ge0rG

    jonasw: but it's real work. Work for people who are more skilled in Lua and mercurial

  31. jonasw

    Seve/SouL, you mean like a separate MUC namespace for each user?

  32. Seve/SouL

    All of that, is under the same service

  33. Ge0rG

    jonasw: I'm looking for corporate clients who would ask for that. None found so far

  34. jonasw

    Seve/SouL, this won’t be possible with MIX either, and I’m not sure if it makes sense at all. A corporate deployment would have a domain anyways and host their services under that domain.

  35. Seve/SouL

    Hmm, I didn't have companies in mind now, but imagine a large company. They would have an xmpp server, and each department would create their own MUCs inside the department's namespace. Like: IT namespace> Frontend dev, Backend dev, DevOps, etc

  36. Ge0rG

    Seve/SouL: that's great. Except that's not how large companies work

  37. MattJ

    Seve/SouL, you can have as many MUC domains as you like

  38. Ge0rG

    Seve/SouL: today's bigcorp want a cloud-based / private-cloud deployment that's fully integrated into their CMDB and AD and stuff

  39. MattJ

    Which just about any XMPP server provides

  40. Ge0rG

    MattJ: are you speaking of AD integration or of "as many MUC domains as you like"

  41. MattJ

    Both

  42. jonasw

    (conference.jabber.org really could use some cleasing)

  43. Seve/SouL

    I understand what you say MattJ. But I think it would be interesting to explore that feature, as Anu said Slack works that way and Discord too. Of course they have this feature because they provide this service, and this feature maybe would not be useful for someone using XMPP just to talk with friends, but...

  44. Ge0rG

    MattJ: so you can write the instructions to set up a prosody for modern clients, including AD integration and a web client, on a napkin?

  45. MattJ

    Most likely, yes

  46. MattJ

    And if you ask why not already done - everyone has a different set of requirements

  47. MattJ

    You may think it, but not every organisation uses AD, or needs/wants a web client

  48. jonasw

    Seve/SouL, I agree that a hosted thing which allowed to easily add a domain, have a tickoption "[ ] Federate with other servers" and otherwise just deploys a modern XMPP server would be great, but time & money

  49. jonasw

    I doubt that one can write down the instructions for integrating with LDAP on a napkin.

  50. jonasw

    picking auth_ldap vs. auth_ldap2 is a non-trivial choice to start with :)

  51. Ge0rG

    MattJ: I know how complex it is to set up a prosody instance for non-commercial users, with less strict requirements. And it won't fit on a napkin.

  52. MattJ

    jonasw, Prosody's LDAP module was designed to work with no-to-minimal configuration a typical Debian/Ubuntu LDAP setup

  53. MattJ

    What I'm saying though is that there is no "standard set-up" (for anything)

  54. MattJ

    Everyone has their own requirements and stuff they want to configure, including Ge0rG

  55. jonasw

    there is no standard LDAP setup, from what I can tell :)

  56. jonasw

    but maybe that’s just me

  57. MattJ

    There is not, but there are many. The one that Debian tries to encourage you into is one

  58. MattJ

    If anyone thinks that enterprise deployment of any integrated software fits on the back of the napkin, they're plainly wrong

  59. MattJ

    The reason things like Slack succeed is precisely because they tend to bypass all that in the beginning

  60. jonasw

    yeah

  61. Ge0rG

    MattJ: then people realize how expensive Slack is and want a single-click deployment. And end up with Mattermost

  62. jonasw

    or rocket.chat

  63. jonasw

    MattJ, any luck with the MUC nuking?

  64. Ge0rG

    MattJ: there are some requirements that you can't argue are optional, like 0198, carbons and MAM

  65. MattJ

    I haven't used Mattermost, but I don't find rocket.chat very high quality software

  66. jonasw

    MattJ, still it replaced XMPP at the company I work for.

  67. jonasw

    because of -- among others -- rich text messages (beyond markdown-ish things) for integrated services...

  68. Guus

    (I was mentioned here, but can't find the mention in recent history)

  69. Guus

    (or my client is acting up)

  70. jonasw

    Guus, I was talking about the webrtc-conference-integration work you are doing

  71. MattJ

    jonasw, I don't seem able to access the server, so... no

  72. jonasw

    MattJ, aw, pity

  73. jonasw

    I’ll try annoying folks in iteam@

  74. Guus

    ah, yeah. We have Jitsi Meet as an Openfire plugin.

  75. MattJ

    Technically iteam doesn't manage jabber.org, but there is, umm, significant overlap...

  76. jonasw

    yupp :)

  77. jonasw

    (checked the volunteers site on jabber.org, found half of iteam there :))

  78. jonasw

    so now I’m abusing the better signal/noise ratio in that room for my cause!

  79. jonasw

    on a different but related note: I launched https://muclumbus.jabbercat.org/ into public beta today. It’s a replacement for http://search.wensley.org.uk/ . criticism, improvement suggestions, bug reports etc. welcome

  80. jonasw

    on a different but related note: I launched https://muclumbus.jabbercat.org/ into public beta today. It’s a replacement for http://search.wensley.org.uk/ , so it’s a "search engine" and listing service for public MUCs . criticism, improvement suggestions, bug reports etc. welcome

  81. Wiktor

    replacement? ha! hardly... no comic sans! just kidding of course, looks very professional, will it provide a JSON endpoint?

  82. jonasw

    Wiktor, thanks, and yes, some type of JSON endpoint which allows to enumerate rooms is on the TODO list

  83. jonasw

    gotta run now though

  84. Wiktor

    great, see ya

  85. Ge0rG

    Lync is now appending ads to the "missed messages" email. Ads for the Lync mobile app.

  86. goffi

    jonasw: great ! Is there a way to query this by XMPP ?

  87. Ge0rG

    jonasw: how comes there is no info about many MUCs?

  88. Ge0rG

    jonasw: it's also missing the room name from disco#info :(

  89. Ge0rG

    something like "Name (<jid>)" in the first line?

  90. Ge0rG

    I know it's the localpart in 99% of the cases, but I have an agenda to change that.

  91. Andrew Nenakhov

    I think we'll be ready to show a working prototype of proper groupchat replacement this week

  92. Andrew Nenakhov

    With client that will support it too

  93. muppeth

    jonasw for servers/rooms supporting muc vcard would be nice to include that in the room stats.

  94. Ge0rG

    Andrew Nenakhov: that reminds me of the promises the ejabberd team made back then instead of implementing XEP-0198.

  95. Holger

    Ge0rG will never forget that.

  96. Andrew Nenakhov

    Yes, we replaced those too and implemented them in forked ejabberd

  97. Andrew Nenakhov

    Just not supported in clients yet

  98. Ge0rG

    Holger: feel free to provide me with a bettter example of XMPP vaporware. MIX doesn't count.

  99. Andrew Nenakhov

    Groupchat is a much easier problem.

  100. Ge0rG

    Except it's not.

  101. Kev

    It's an easy problem. It's the solutions that are easy to get wrong :D

  102. Andrew Nenakhov

    It is. You might join our group chat when now.

  103. Andrew Nenakhov

    I can send you invitation if you want

  104. Holger

    Ge0rG: They tried stuff and it failed, that's all. I still fail to see the drama.

  105. Holger

    Ge0rG: And it's not like 0198 works well.

  106. Ge0rG

    Holger: the drama is about to making empty promises for years about a feature that's really needed for mobile clients.

  107. Ge0rG

    Holger: it's got its rough edges, but it works much better than not having it.

  108. Holger

    Yeah, they've been busy with other stuff.

  109. Kev

    Who hasn't?

  110. Ge0rG

    But I know I'm a highly controversial ultra progressive revoluzzer regarding XMPP support for mobile devices.

  111. Ge0rG

    ...or reliable message delivery.

  112. Andrew Nenakhov

    Actually, we do have progress on this front too.

  113. Andrew Nenakhov

    ;)

  114. Ge0rG

    Andrew Nenakhov: I'm curious to see your design

  115. Andrew Nenakhov

    Ok

  116. Andrew Nenakhov

    Give me a minute

  117. Andrew Nenakhov

    Ge0rG, add xsf@xmppdev01.xabber.com to your contact list

  118. Ge0rG

    Andrew Nenakhov: what will happen then?

  119. Andrew Nenakhov

    You'll be in our group chat

  120. Andrew Nenakhov

    Best accessed with Xabber for Web, https://web.xabber.com/develop/

  121. Andrew Nenakhov

    But we've added backwards compatibility for old clients too.

  122. Ge0rG

    Andrew Nenakhov: I'm interested in the protocol design :)

  123. Andrew Nenakhov

    Document is in Russian, will take some time to translate

  124. Andrew Nenakhov

    But basic idea is simple

  125. Ge0rG

    Andrew Nenakhov: I can handle Russian

  126. Andrew Nenakhov

    Member sends message to jid of group chat, server resends it to other members

  127. Ge0rG

    That sounds like GC1 ;)

  128. Andrew Nenakhov

    For old clients it adds line with name of sender, like, GeOrG: Whatever

  129. Andrew Nenakhov

    > That sounds like GC1 ;) I actually didn't find specification for that

  130. Andrew Nenakhov

    Only mention in muc-0045

  131. Wiktor

    What is received by new clients? is there an extra xml?

  132. Andrew Nenakhov

    But yeah, so far we didn't encounter anything that would be game breaking by this approach

  133. Andrew Nenakhov

    Wiktor, yes

  134. Wiktor

    Sounds interesting, and simple, also looking forward for the spec

  135. Andrew Nenakhov

    Every message is accompanied by jid of sender, and his avatar hash

  136. Andrew Nenakhov

    Server also fetches username and avatar from members vCards

  137. Andrew Nenakhov

    User can replace them

  138. Andrew Nenakhov

    Also server sends a specially formatted presences so clients can differentiate group chats from regular contacts

  139. Wiktor

    why wasn't resource part of JID reused as a nick? so that this group chat was somehow distinguished from 1:1 chats?

  140. Andrew Nenakhov

    Because we didn't think it is necessary )

  141. Wiktor

    got it :)

  142. Andrew Nenakhov

    And also too many ears were fought on this issue

  143. jonasw

    goffi, re querying muclumbus via XMPP: not yet, but that’s on my todo

  144. Ge0rG

    Andrew Nenakhov: do you have a (Russian) spec you can share?

  145. jonasw

    Ge0rG, many MUCs don’t publish a description, that’s why there is no info

  146. jonasw

    Ge0rG, regarding using the room name, many of the top 25 MUCs have a horrible room name (e.g. room name == description); I haven’t found a layout which makes that look nice. I have the data though.

  147. goffi

    jonasw: cool

  148. jonasw

    muppeth, could you be more specific regarding the vcard thing? I am reluctant adding third party images on the listing because of the huge potential for abuse.

  149. Andrew Nenakhov

    Ge0rG, I can share it tomorrow if you don't mind. Too many dirt right now,

  150. jonasw

    Ge0rG, maybe ellipsizing the room name after 50 characters or something would, but meh.

  151. Andrew Nenakhov

    We do a room name and separate jid. Jby default client is doing a slug of group name, but it can be redefined

  152. Ge0rG

    jonasw: yeah, name, description and topic are handled in weird ways. I still think we should promote the name, and my favorite layout would be: > Room Name (jid@domain) > romm description (if different from room name)

  153. jonasw

    that looks awful, trust me

  154. Ge0rG

    Andrew Nenakhov: slug-of-groupname is a great way.

  155. Ge0rG

    jonasw: one day you'll end up with uuid MUC JIDs.

  156. jonasw

    there are a few already :)

  157. Kev

    Swift generates those.

  158. Ge0rG

    Kev: for public MUCs as well?

  159. Kev

    Of course not :)

  160. jonasw

    this is luckily public MUCs only :)

  161. jonasw

    Ge0rG, hm, reverting to the current layout for room name == room description could work though

  162. Ge0rG

    jonasw: I agree with you that most people can't properly define the room name.

  163. Ge0rG

    There is a bunch of positive exceptions, though.

  164. jonasw

    Ge0rG, really bad is the case for kuketzblog, which has no description, but a string which should be the description as name

  165. jonasw

    Kev, while you’re here, can you fix the room name for this room please?

  166. jonasw

    it is equivalent to the subject

  167. Ge0rG

    I think it's symptomatic for the XSF to not be able to properly apply our own standards.

  168. Kev

    I imagine it's someone using a client that's doing silly things.

  169. Kev

    Although what the name *should* be, I have no idea.

  170. jonasw

    "XSF Discussion"?

  171. Kev

    Indeed, that's what I set it to.

  172. Ge0rG

    "XMPP Standards Foundation"

  173. jonasw

    or that

  174. Ge0rG

    "XMPP Discussion" would be a good one as well

  175. jonasw

    Ge0rG, force-reload https://muclumbus.jabbercat.org/

  176. jonasw

    Ge0rG, xmpp@chat.yax.im is also a bad example regarding room name, by the way

  177. Ge0rG

    jonasw: thanks! nitpick: name of conversations@conference.siacs.eu is "Conversations", so not strictly equall

  178. jonasw

    Ge0rG, no, it’s "conversations"

  179. jonasw

    identities: category='conference' type='text' [en] 'conversations'

  180. Andrew Nenakhov

    jonasw, list of chats should say "XMPP discussion", and whatever yax.im part is not really important for users once they are in room

  181. Ge0rG

    jonasw: changed the xmpp@chat.yax.im name. When will it refresh?

  182. Wiktor

    hmm... hiding jids in case there is name... it would look like google :)

  183. jonasw

    Ge0rG, the about page tells you it takes something about one hour

  184. jonasw

    Wiktor, I’m considering hiding the JIDs in case there is a name, but then I’ll have to consider how to handle matches inside the JID in the search list

  185. Wiktor

    personally I would move online users count closer to the name / description. On bigger screens it's hard to read the room name description and count without excessive eye movements :) maybe that's just me :)

  186. Wiktor

    one way or another big 👍, this service is really good

  187. jonasw

    thanks

  188. jonasw

    regarding the online user positioning, I don’t think there’s a good way for that since this is a table :/

  189. jonasw

    (and I don’t want to move the online count into the text field because it’ll be hard to discover it)

  190. Wiktor

    yeah, I mean on mobile the data is compressed and it looks good, on laptop the important info (user count) is far away

  191. jonasw

    on my laptop it’s fine

  192. Ge0rG

    Have the number to the left

  193. jonasw

    Ge0rG, would have to trick CSS to make that happen

  194. jonasw

    not sure if browsers support that

  195. Ge0rG

    jonasw: what about reordering the table items? Too easy?

  196. jonasw

    Ge0rG, not accessible

  197. jonasw

    although, with a table it’d probably work

  198. jonasw

    there doesn’t seem to be a way to do this with CSS, but I’ll look into how bad reversing the columns would be

  199. Wiktor

    did I get this right that there is also planned "room language" to be displayed?

  200. jonasw

    Wiktor, yes

  201. Wiktor

    gret

  202. jonasw

    once servers support that

  203. Wiktor

    great

  204. Wiktor

    yes, and once it's set up by room operators

  205. jonasw

    follow https://github.com/processone/ejabberd/issues/2436 and https://issues.prosody.im/1149 :)

  206. jonasw

    sure

  207. jonasw

    I need to get back to work on my thesis now though

  208. Wiktor

    good luck :)

  209. jonasw

    (which unfortunately isn’t "Enumerating chat rooms in a federated chat network")

  210. Ge0rG

    jonasw: you need a better thesis supervisor then.

  211. jonasw

    Ge0rG, dunno, I find "port this thing so that we can run it on a satellite which’ll be shot into space next year" fine, too

  212. Ge0rG

    Nobody can compete with satellites...

  213. jonasw

    (also, my supervisor is actually an XMPP fan)

  214. Ge0rG

    jonasw: I'm an xmpp fan as well, despite what I'm writing, and I'm a certified thesis supervisor. But I don't have satellites... 😒

  215. jonasw

    aww

  216. dwd

    I've just spent ten minutes debugging ahy this app isn't using SASL2.

  217. dwd

    No matter what I did, it kept using the urn:xmpp:sasl:1 namespace.

  218. jonasw

    then you realized that that IS the SASL2 namespace?

  219. jonasw

    while the other one would be urn:ietf:something?

  220. dwd

    jonasw, Exactly.

  221. dwd

    jonasw, One day I'll figure out some non-trivial update to SASL2, so the namespace can align properly. :-)

  222. Kev

    Until the next one.

  223. Ge0rG

    which will be the bugfix release.

  224. Ge0rG

    what about using `urn:xmpp:sasl2:1` instead?

  225. Zash

    what about urn:xmpp:sasl2000

  226. dwd

    Ge0rG, Still a namespace change. No, I think it's doomed to be sasl:1 forever.

  227. Ge0rG

    "Status: Experimental". Doesn't look very doomed to me.

  228. Ge0rG

    I wouldn't be surprised if dwd turned out to be the (co)owner of all existing implementations.

  229. edhelas

    actually XMPP is only made by dwd, everyone else in this chatroom are just multi

  230. edhelas

    I have a question regarding 0045

  231. jonasw

    we all do

  232. dwd

    Ge0rG, Surevine is, I think, for now. Phil Roberts did one in Stanza.io, and I did one in Openfire. Neither's been pushed upstream, which I'd like to rectify.

  233. edhelas

    muc#roominfo_pubsub, it's not specified in the XEP where this is exposed when set, it would be nice to say that somewhere

  234. dwd

    (Man there are times I want a +1 for '45, and jonasw, that was one of them)

  235. jonasw

    edhelas, roominfo_pubsub is a disco#info form field

  236. edhelas

    ah :D

  237. edhelas

    let me check that on ejabberd

  238. dwd

    edhelas, I'd take that one with a pinch of, well, anything. I don't think it has sufficient semantics defined to be useful in an interoperable manner.

  239. jonasw

    Ge0rG, your update to the xmpp@chat.yax.im room has propagated :)-

  240. jonasw

    I don’t find it a good name still, though

  241. Ge0rG

    jonasw: I still think it should be printed on a t-shirt.

  242. Ge0rG

    It's a much better description of MUC than anything you'll find in '45

  243. jonasw

    but not a good descrition of the room

  244. Ge0rG

    jonasw: I might reconsider a more on topic name once the current name gets painted onto some official XSF property.

  245. jonasw

    there is official XSF property?

  246. Ge0rG

    Like this MUC

  247. dwd

    jonasw, All the XEPs, for one thing.

  248. jonasw

    right, for some reason I was picturing Ge0rG with a spray can in front of a house wall in my head

  249. jonasw

    SCHRÖDINGERS CHAT would be a cool tag

  250. Ge0rG

    jonasw: and a black hoodie. And the only light comes from a MacBook screen

  251. jonasw

    itym the apple thing on the back side of the screen

  252. jonasw

    which you taped over with a matrix sticker

  253. Ge0rG

    jonasw: that, too

  254. Ge0rG

    Are we speaking of Matrix or of *the* Matrix, though? 🤔

  255. jonasw

    that one movie, of course

  256. Ge0rG

    those three movies which actually are just one movie?

  257. Ge0rG

    It's complicated™

  258. jonasw

    nah, the one movie where people always thing sequels exist

  259. jonasw

    but they’re wrong

  260. jonasw

    do you folks think it would be good to add a specified disco#info/disco#items response (part) which allows things to discover anonymous ways to access MUCs?

  261. jonasw

    I’m thinking e.g. a disco#info form field which gives the XMPP domain of a service which allows ANONYMOUS login and access to a room

  262. jonasw

    I’m thinking e.g. a disco#info form field which gives the XMPP domain of a service which allows ANONYMOUS login and access to the room

  263. jonasw

    that would allow to add a "join in browser" button e.g. for support MUCs where such a facility is available.

  264. MattJ

    Yes yes yes

  265. edhelas

    well I think that Movim is now the first XMPP client to make use of muc#roominfo_pubsub /o/

  266. MattJ

    edhelas, from which spec?

  267. edhelas

    0045

  268. MattJ

    Ha, what... that's been in there since 2006?

  269. edhelas

    looks like :D

  270. MattJ

    But there are no details on what it contains

  271. dwd

    (More or less what I said earlier)

  272. dwd

    I suspect it was from the days of "LETS PUBSUB THIS PUB SUB THING!"

  273. Ge0rG

    So it's a reference to a pubsub node containing a list of the pubsub nodes associated with this MUC?

  274. dwd

    Ge0rG, Well, that'd make it a collection node, and those are unfashionable now.

  275. Ge0rG

    because nobody can figure out if it's an item of elements or a list of items of one element each?

  276. edhelas

    for me it's just pointing to a pubsub node

  277. edhelas

    that's it

  278. Ge0rG

    look, ma! a pubsub node!

  279. edhelas

    :p

  280. Ge0rG

    So who volunteered to re-do XEP-0357 with messages instead of pubsub, again?

  281. MattJ

    Ge0rG, I don't think XEP-0357 really does use pubsub

  282. Holger

    Well I see no real problem with the PubSub-like syntax except that it misleads people to believe they could use a standard PubSub component to implement an app server.

  283. Ge0rG

    It's misleading and it's adding overhead to understanding the protocol

  284. Ge0rG

    And it isn't even actual PubSub.

  285. Holger

    I agree, but the question is whether cleaning this up is worth the compat foo you run into.

  286. Holger

    Then again the number of public app servers isn't too large I guess ...

  287. Ge0rG

    Holger: who would use a public app server anyway?

  288. Holger

    Er what?

  289. Ge0rG

    Holger: most clients are bound to use their specific one.

  290. Holger

    I meant app servers for publicly available clients.

  291. Ge0rG

    Holger: if the XMPP server component supports both protocols, there won't be any compat issues

  292. Ge0rG

    Holger: client devs who start at zero just implement the simple protocol in their app server / clients and be done.

  293. Ge0rG

    legacy push installations remain as is

  294. Ge0rG

    legacy authors sick of the pseudo-pubsub switch to the new protocol on a separate host name.

  295. Ge0rG

    But yes, it's good enough™ and nothing will happen about the status quo.

  296. Ge0rG

    at least it doesn't have a siacs namespace.

  297. MattJ

    It will if someone cares enough to write up the new protocol

  298. MattJ

    If they don't, then sure, it will stay the same because it's deployed and working

  299. Ge0rG

    and working(*)

  300. Ge0rG walks himself out. It's way too hot to be ranting about things that are good enough™

  301. Holger

    I just think we have more pressing issues than this syntax weirdness but I won't stop anyone of course.

  302. Zash

    Rough consensus and running code?

  303. Holger

    Ge0rG: I totally agree 0357 isn't good enough. It's not enough to implement working push notifications.

  304. Ge0rG

    Whenever I start reading 0357, and I arrive at the first mention of 0060, my brain phases out.

  305. Holger

    Ge0rG: As for the syntax issue, you then need to decide whether to stick to (non-PubSub) IQs or rely on https://xmpp.org/extensions/xep-0357.html#sect-idm140285094926944 for error processing.

  306. Ge0rG

    Unfortunately, that first mention is in §1 Introduction.

  307. Holger

    Yes that §1 'Note:' is insane.

  308. MattJ

    Ge0rG, in the simple-protocol world, what would your next steps be? How would you implement your app server?

  309. Holger

    Ge0rG: Purging that 'Note:' would be a good first step IMO.

  310. Zash

    PubSub supports added payloads in the notification, at least for a <body>

  311. Ge0rG

    MattJ: I don't understand the current XEP enough to make proper suggestions.

  312. Ge0rG

    Probably actually implementing the protocol will improve my understanding enough to pinpoint the issues other develoeprs are highlighting for a year or so.

  313. Ge0rG

    > The full process for enabling notifications requires initializing two separate push services: between the App Client and App Server, and between the App Server and the user's XMPP server. The XEP isn't actually helpful in making its point, either.

  314. Ge0rG

    The Note in §5 is even more absurd than the one in §1

  315. Ge0rG

    I need IBR to provision the push service node? What?

  316. Holger

    "possible, but not required"

  317. Holger

    Yes I'd ditch that sentence too.

  318. Ge0rG

    Holger: please send PRs

  319. Holger

    Yaxim needs to register with push.yax.im somehow. That's all.

  320. Holger

    The XEP doesn't tell you how because no need for standardization.

  321. Holger

    ChatSecure uses some REST calls, Conversations some ad-hoc commands.

  322. Holger

    Nobody uses IBR, AFAIK :-)

  323. Ge0rG

    Holger: somebody needs to streamline that XEP, then.

  324. Holger

    Yup.

  325. Holger

    I offered to maintain it back when Lance quit.

  326. Ge0rG

    Holger: what happened next?

  327. Holger

    Kev took over -> less work for me -> Holger happy!

  328. Seve/SouL

    Seve happy to see Holger happy

  329. Ge0rG

    Kev: XEP-0357 sucks big time. Please fix.

  330. Ge0rG

    Holger: you still could send strategic PRs.

  331. Zash

    Not enough happiness to go around apparently

  332. Holger

    Probably happier community because I would've suggested adding business rules and whatnot. While I think the general consensus is rather to keep things unspecified in order to not loose flexibility.

  333. Ge0rG

    Like.. PubSub and IBR

  334. Ge0rG

    > It is NOT RECOMMENDED to allow in-band modification of push notification content settings. Such operations SHOULD be done out-of-band to prevent privilege escalation. What?

  335. Ge0rG

    Holger: business rules would be great.

  336. Holger

    Ge0rG: Forget that configuration stuff. Should also be ditched. It's per-account rather than per-device and the idea seems to be that *users* configure things.

  337. Holger

    Nobody implements this.

  338. Ge0rG

    So the XEP creates a smoke-screen of distractions for how to do irrelevant stuff, is using an overengineered protocol for the parts that it *does* specify, and is lacking a description of how to be applied properly?

  339. Ge0rG

    Am I missing something?

  340. daniel

    Yeah the xep is a lot harder to understand than to implement

  341. daniel

    You can write an app server and the client code in a few hours

  342. daniel

    But it's pretty bad at communicating what you have to do

  343. daniel

    I don't _mind_ the overhead of pubsub. It actually allows you to reuse parts of your library which was probably the reason it does use pubsub Syntax

  344. daniel

    But it's really distracting and leads you on the wrong path

  345. Ge0rG

    daniel: you mean it allows you to reuse parts of your *pubsub library*, provided you have one?

  346. Ge0rG

    daniel: as a client developer who implemented it, maybe you can provide some strategic PRs to the XEP to make it less horrible?

  347. daniel

    well after three years of trying to get the business rules in and failing i don't really feal like it tbh

  348. daniel

    so my general recommendation to new comers is just to ignore the fact that it uses pubsub *syntax*

  349. Ge0rG

    daniel: what was the issue with the business rules?

  350. Ge0rG

    It can't be *that* hard to get a PR merged?

  351. Ge0rG is naive today.

  352. daniel

    well if we had a mailinglist / forum / archive that would be searchable it'd be really easy to dig up those threads

  353. MattJ

    https://mail.jabber.org/pipermail/standards/2016-February/030925.html

  354. Ge0rG

    Date: Tue, 16 Feb 2016 13:32:16 +0100 From: Daniel Gultsch <daniel@gultsch.de> To: XMPP Standards <standards@xmpp.org> Subject: [Standards] XEP-0357: Push Notifications is missing business rules section

  355. Ge0rG

    I don't see any refuseniks on that thread

  356. MattJ

    From reading that, it appears to say that every message added to the archive should generate a push? (i.e. almost every chat message)

  357. MattJ

    Is it meant to imply that's only for when the client is offline?

  358. Ge0rG

    MattJ: that implies the question what "offline" exactly means.

  359. Ge0rG

    I think we can agree that we need a push when the client is in 0198 hibernated state. But what if our server stack hasn't noticed a client hibernation event yet?

  360. MattJ

    I've been thinking about pinging more aggressively after an "important" stanza was sent to a client

  361. MattJ

    i.e. after an important stanza is sent, follow it with a <r> and have a low <60s timeout waiting for the <a>

  362. Holger

    That's what ejabberd does, except after any stanza (except when it didn't receive the responce to the previous <r/>equest yet).

  363. Ge0rG

    MattJ: yes, following important stanzas with an <r> is great anyway

  364. daniel

    MattJ: yes that's the third rule or something

  365. daniel

    The offline one is the first

  366. MattJ

    So to clarify, you're saying it should send the message via push even if it believes the client is actively connected?

  367. daniel

    Only if you haven't received the ack

  368. daniel

    What Holger said basically

  369. MattJ

    Ok, just your business rules don't mention anything about acks

  370. MattJ

    It makes it seem like the push is unconditionally sent for any message that gets added to the archive

  371. daniel

    right. yeah that should be clarified. for each push token only one of (a), (b) or (c) applies

  372. Zash

    Don't it send when CSI is on as well

  373. Ge0rG

    Don't send the push? Why not?

  374. daniel

    right. or only for stanzas that actually move down stream

  375. Ge0rG

    I mean, I'd assume you should send a push whenever a CSI queue flush happens

  376. daniel

    not for those held back by csi

  377. Kev

    Surely you want to push especially when CSI is active?

  378. Zash

    Ge0rG: Send all the time, for every stanza!!!

  379. Kev

    Because then the user gets to see the notification and can bring their client up to view it.

  380. Zash

    Doesn't it* maybe

  381. daniel

    Anyway Holger or Tilo are probably the better people to write it down having actually implemented it

  382. MattJ

    Kev, you mean "inactive"? :)

  383. daniel

    I mean I still have it in my head somewhere but I might be forgetting details

  384. Kev

    When the client is inactive, when CSI is active.

  385. Kev

    Whatever.

  386. Ge0rG

    Kev: would you mind giving the XEP over to Holger so we can clean up the mess?

  387. Zash

    Moar ambiguous!

  388. Ge0rG

    And by "we" I mean "he" :>

  389. Kev

    Ge0rG: Patches welcome.

  390. Ge0rG

    Holger: ^

  391. Kev

    I think the basic logic is "Wait a bit after a stanza, see if you get an ack from the client, if you don't then send a push notif", right?

  392. Holger

    Kev: My impression was that you're not happy with business rules.

  393. Holger

    Kev: https://mail.jabber.org/pipermail/standards/2017-May/032701.html

  394. Kev

    I think I said that I was in favour of them, just not normative, didn't I?

  395. Kev heads off to check what he wrote.

  396. Kev

    Yes, I did :)

  397. Ge0rG

    > I came up with a somewhat different scheme, which I’d like to also be allowable Yay!

  398. Holger

    Another thing that needs addressing is the "ChatSecure case" where the app server basically wants to know whether the notification was triggered by a human-readable message or not.

  399. Holger

    Or some per-client configuration to limit notifications to only specific types of stanzas.

  400. Ge0rG

    Holger: what kind of non-human-readable events should trigger push?

  401. Holger

    Chris suggested this: https://mail.jabber.org/pipermail/standards/2017-July/033085.html

  402. Ge0rG

    There is really no excuse for low-priority pushes.

  403. Holger

    Ge0rG: Jingle calls, any other IQs, or if you try to keep a 0198 session alive, actually any stanza.

  404. Zash

    Cache stuff maybe?

  405. Ge0rG

    Holger: jingle calls are high prio

  406. Holger

    Then again you could argue that keeping the session alive is an ugly hack that needs to be fixed anyway.

  407. Zash

    Like disco

  408. Ge0rG

    the only excuse I can see is "okay client, I haven't heard of you in a day now, and I have those 10000000 stanzas for you in my 0198 queue. Please come and fetch them any time soon"

  409. Holger

    Ge0rG: Yes, except that I will do this with a way lower number of stanzas.

  410. Kev

    Ge0rG: Why not just drop the stanzas?

  411. Kev

    At that point you're almost guaranteed most are stale.

  412. Ge0rG

    Kev: because the Gods of XMPP will be mad.

  413. Holger

    Ge0rG: So IQs should just time out?

  414. Ge0rG

    Kev: you can't simply drop stanzas from mid-stream, you'd have to terminate the 0198 hibernated session.

  415. Kev

    Yes, that's what I mean.

  416. Ge0rG

    Holger: I have no easy answer to that.

  417. Holger

    Ge0rG: Sending clients should cope with such timeouts? (Currently they don't.)

  418. Holger

    Ah.

  419. Ge0rG

    Holger: somebody should write Business Rules.

  420. Ge0rG

    Holger: the path of least breakage would be to low-prio-push the client on an incoming IQ, yes. The better long-term solution would be to respond from the server.

  421. Ge0rG

    Maybe a mid-way would be to kill the 0198 zombie on an incoming full-JID IQ ;)

  422. Holger

    Long-term I'd ditch the 0198 session.

  423. Holger

    Right now we this will break notifications for MUC messages.

  424. Ge0rG

    Holger: but session establishment is expensive

  425. Holger

    That should be fixed.

  426. Ge0rG

    In addition to roster versioning, we'd need presence versioning.

  427. Holger

    I think Kev argued that way and I agree on this.

  428. Holger

    But I'd like to make push notifications work before the year 2025 and I think we need the 0198 hack until then.

  429. Ge0rG

    I think somebody proposed to treat XMPP IM as a database synchronization problem, some time ago

  430. Ge0rG

    Holger: I agree

  431. Kev

    By the 198 hack, do you mean sending of <r/> or killing sessions?

  432. Holger

    Kev: Keeping sessions alive for disconnected push clients.

  433. Ge0rG

    So yes, I'm convinced we need two push priority types.

  434. Holger

    Kev: Mostly to get MUC notifications.

  435. daniel

    > I think somebody proposed to treat XMPP IM as a database synchronization problem, some time ago Isn't that matrix?

  436. Kev

    Sorry, I've suddenly realised I've missed a whole part of this.

  437. Kev

    Ah, MUC, right.

  438. Kev

    Yes, MUC doesn't work with multi-client. We should replace it. Let's call the replacement MIX )

  439. Kev

    :)

  440. Ge0rG

    daniel: I didn't say *distributed* database sync.

  441. Holger

    An alternative might be implementing some other hack to keep you joined.

  442. Holger

    Kev: "But I'd like to make push notifications work before the year 2025"

  443. Ge0rG

    Kev: yes, let's also add a dozen of unrelated features into it to make it hard to implement.

  444. Kev

    I don't think anything in it is unrelated :)

  445. Kev

    But yes, we don't have MIX right now. Hacks until then seems likely.

  446. Ge0rG

    Are there any experience values on the delivery jitter of low-prio pushes on iOS? They are deemed "unreliable"

  447. Holger

    Ge0rG: Seems to vary a lot. I think it depends on things such as the current battery level, on the notification rate, on how frequently you use the app, on the moon and who knows what.

  448. Ge0rG

    Holger: let me rephrase my question: is the median latency of low-prio push sufficient to obtain IQ results without the remote side timing out, typically?

  449. Holger

    Ge0rG: I.e. on some devices, silent notifications seem mostly reliable; other users seem to never receive them; others are in between.

  450. Ge0rG

    Is there some kind of distribution curve on the notifications that do arrive?

  451. Holger

    Ge0rG: Dunno numbers, but either way you can't rely on it. So ejabberd actually won't let low-prio pushes trigger a timeout of the pending 0198 session. But yes the IQ will time out.

  452. Kev

    daniel / Holger: To check I understand, the rules here are basically: * Make sure the server has a list of all clients/push requirements and a map from these to sessions * On a new pushable event, send for everything that doesn't have a session, or where the session isn't sufficiently responsive And that's the crux of it?

  453. daniel

    Kev: yes

  454. Kev

    In terms of normative text, the 'know who I am' seems sensibly normative, and the 'responsive sessions' seems like a suggestion to me.

  455. Holger

    Yes.

  456. Holger

    A suggestion that could go into 0198 I guess.

  457. Kev

    Ah, no, that's different.

  458. Kev

    You both want Push to say "If it's not responsive, send anyway" and then you might want 198 to say "terminate if unresponsive", but those aren't the same.

  459. Holger

    Ok.

  460. Kev

    Don't you?

  461. Holger

    Yes I agree. Sometimes I'm easy to convince :-)

  462. Ge0rG

    Holger: so you just agreed to write down all the biz rules? Great!

  463. Ge0rG

    !praise Holger

  464. Zash

    ^C^V Kevs sumary?

  465. Ge0rG

    It's confusing how Conversations is both #1 and #6 of the MUC list.

  466. jonasw

    will be better once we have language information

  467. jonasw

    which was the dino MUC again?

  468. Ge0rG

    chat@dino.im IIRC

  469. jonasw

    this is weird

  470. Ge0rG

    It is. And the domain isn't even a MUC domain, breaking poezio's MUC discovery.

  471. jonasw

    yeah

  472. jonasw

    not only poezios

  473. MattJ

    -version dino.im

  474. Bunneh

    MattJ: dino.im is running Prosody version 0.10.0 on Linux

  475. MattJ ducks

  476. Zash

    Component "chat@dino.im" "muc" ?

  477. Zash hides

  478. jonasw

    Zash, seems more like modules_enabled = {"muc"} to me

  479. Ge0rG points at `@conference.jabber.org`

  480. jonasw

    no, the domain doesn’t expose the muc feature

  481. Zash

    jonasw, don't think you can do that

  482. Zash

    jonasw, you can make a bare jid a component tho

  483. jonasw

    super-weird thing

  484. Zash

    disco integration might not work tho, maybe we should fix that

  485. jonasw

    at least the disco#items isn’t confusing

  486. jonasw

    please don’t

  487. Zash

    -contact prosody.im

  488. Bunneh

    Zash: prosody.im doesn't have any contact addresses

  489. Ge0rG

    What about forbidding such corner cases?

  490. Zash

    Ge0rG, ytho

  491. jonasw

    Ge0rG, you might wanna destroy dino@chat.yax.im btw

  492. Ge0rG

    There really is no reason to allow joining a bare JID MUC, or to have a MUC on a non-MUC domain.

  493. jonasw

    Ge0rG, I agree on the former, but not necessarily on the latter

  494. Ge0rG

    Info> Room dino@chat.yax.im destroyed

  495. jonasw

    \o/

  496. Ge0rG

    Okay, it's breaking assumptions that need to be shaken up from time to time. But I'm pretty sure we have enough corner cases for client devs to care about, without adding such oddities

  497. Zash

    Is there really anything in the protocol that forbids it tho?

  498. Ge0rG

    No.

  499. jonasw

    if the disco#items were correct (i.e. contained the MUC), it might be okay actually

  500. Zash

    jonasw, that's what I was referring to for fixing

  501. jonasw

    yeah

  502. jonasw

    I’m not that scared of the result anymore

  503. jonasw

    I’m scared though what’ll happen when conference.jabber.org is fixed.

  504. jonasw

    that’ll be some serious amount of data :)

  505. Ge0rG

    I hope we are going to end up with less Conversations on the top 10 list.

  506. Zash

    Isn't it in dire need of some spring cleaning?

  507. jonasw

    Zash, very dire, very need

  508. jonasw

    Ge0rG, I doubt that

  509. Zash

    The existence of conversations@conference.confersations.im is especially confusing

  510. Zash

    covfefesations

  511. jonasw

    Ge0rG, but if that bothers you, maybe you could go and find more MUC servers :)

  512. Ge0rG

    https://xmpp.org/extensions/xep-0045.html#disco-service-features "The service MUST return its identity and the features it supports."

  513. Ge0rG

    jonasw: what's the default nickname of Christopher?

  514. Ge0rG

    Maybe it should be called Chatstopher?

  515. jonasw

    Ge0rG, it doesn’t join at the moment, but it defaults to '-C. Muclumbus'

  516. Ge0rG

    jonasw: did you pre-populate it with the MUC domains from the old muc search?

  517. jonasw

    no, the old muc search is kaputt

  518. jonasw

    GDPR’d

  519. jonasw

    I used the compliance tester

  520. jonasw

    added all domains and I have a recursive disco#items explorer going

  521. Ge0rG

    jonasw: https://github.com/pfleidi/yaxim/blob/master/res/values/servers.xml#L124

  522. jonasw

    neat

  523. Zash

    and xmpp.net

  524. jonasw

    let’s insert those

  525. Ge0rG

    jonasw: you can also feed the explorer with the `xmpp_servers` array as well

  526. jonasw

    indeed

  527. jonasw

    meh, again I wish that postgresql had a INSERT ... ON CONFLICT IGNORE thing

  528. jonasw

    oh on conflict do nothing

  529. Zash

    Oh is that the thing preventing us from having nice things with postgres?

  530. Zash

    Was that the thing SQLite has?

  531. intosi

    https://www.postgresql.org/docs/current/static/sql-insert.html

  532. Ge0rG

    I think SQLite has some ON CONFLICT that you can configure when *creating* the table

  533. intosi

    You mean ike the insert into table ... ON CONFLICT DO NOTHING mentioned?

  534. jonasw

    intosi, except that I’m on postgres 9.4, yes

  535. intosi

    No time like the present for an upgrade then ;)

  536. jonasw

    ahaha

  537. jonasw

    that is a ratstail of things for which I’ll need a weekend or so

  538. jonasw

    intosi, did you have any chance to look into @conference.jabber.org?

  539. intosi

    No.

  540. jonasw

    Ge0rG, thanks, that brought a few new domains

  541. intosi

    Between a server upgrade, other work things, and not stopping my beloved keyboard from drinking coffee, I had few cycles left.

  542. jonasw

    (bit over a hundred or so)

  543. jonasw

    intosi, no worries :)

  544. jonasw

    also, sorry for your keyboard

  545. jonasw

    (just wanted to make sure I finally found someone with +w on the right box)

  546. Ge0rG

    jonasw: glad I could help

  547. jonasw

    oh right

  548. Ge0rG

    jonasw: I might also extract some (non-public?) domain lists from s2s logs, spam bot logs etc.

  549. jonasw

    maybe

  550. jonasw

    we need to do something about the invalid data form used by XEP-0157 though

  551. Ge0rG

    Unfortunately I don't have the full search.wensley.org.uk dump any more.

  552. jonasw

    could someone take a quick look on whether this is editorial or not? https://github.com/xsf/xeps/pull/650/files

  553. jonasw

    I feel it is because the form specification in the document already specicfies list-multi

  554. Zash

    I don't think the type attr is required on type=submit (?) forms

  555. Zash

    They'd seem redundant since in most cases you are sending it to the entitiy you got the form from

  556. jonasw

    indeed. type is MAY

  557. jonasw

    damnit

  558. Zash

    Doesn't hurt for readability tho

  559. Kev

    jonasw: I would argue not editorial, it's changing protocol.

  560. Kev

    Or, at least, if you're ever in doubt, just throw it up to Council.

  561. jonasw

    Kev, I’m also wrong, I’m going to close the PR.

  562. Kev

    I'm not even sure that change is 'right', is it?

  563. jonasw

    it is not wrong (type is MAY)

  564. Kev

    One doesn't give the type on a result generally.

  565. jonasw

    but it’s not required either way

  566. jonasw

    > For data forms of type "form", each <field/> element SHOULD possess a 'type' attribute that defines the data "type" of the field data (if no 'type' is specified, the default is "text-single"); fields provided in the context of other forms types MAY possess a 'type' attribute as well.

  567. Kev

    Indeed.

  568. Kev

    So I'd argue that examples containing it is likely to lull people into a false sense of security that they don't have to correlate.

  569. jonasw

    yay, that spawned aioxmpp issue number 200

  570. jonasw

    yupp, gonna retract the PR

  571. Zash

    Hm, if a submitted form has conflicting field types, how loudly should you cry?

  572. pep.

    I'm trying to organize an XMPP sprint ("hackathon", whatever suits you) in Cambridge UK around August (dates TBD). Topics are also TBD. Please join xmpp:xmpp-sprint@chat.cluxia.eu?join if interested :)

  573. pep.

    https://cryptpad.fr/code/#/1/edit/gSOmgqjDKPIBQmeK41-Log/9wCZoyjHTNX07IrrYaJTSbcV/ as a preview, I still have a few info to put in there

  574. Alex

    hey guys, lets start our member meeting in 3 minutes

  575. Guus

    The suspense!

  576. Alex bangs the gavel

  577. Alex

    here is our Agenda for today: https://wiki.xmpp.org/web/Meeting-Minutes-2018-05-29

  578. Alex

    1) Call for Quorum

  579. Alex

    as you can see, 33 members voted via proxy, so we have a quorum

  580. Alex

    2) Items Subject to a Vote

  581. Alex

    new and returning members, you can see teh application page here: https://wiki.xmpp.org/web/Membership_Applications_Q2_2018

  582. Alex

    3) Opportunity for XSF Members to Vote in the Meeting

  583. Alex

    anyone here who has not voted yet and wants to do os now?

  584. Guus

    (sound of crickets)

  585. Zash

    s/crickets/suspensfullness/

  586. Alex

    looks like none, then I will start counting the vote snow ;-)

  587. Alex

    now

  588. Alex

    4) Announcement of Voting Results

  589. Zash

    Drumroll!

  590. Alex

    when you reload teh page at: https://wiki.xmpp.org/web/Meeting-Minutes-2018-05-29#Announcement_of_Voting_Results

  591. Alex

    you can see the results

  592. Alex

    all reappliers were accepted, and we had no new applicants this term

  593. Alex

    congrats to everyone

  594. Alex

    5) Any Other Business?

  595. dwd

    I'd like to say thanks to Alex for a job well done as usual.

  596. Zash

    seconded

  597. Guus

    Thanks Alex!

  598. Alex

    6) Formal Adjournment

  599. Alex

    I motion that we adjourn

  600. dwd

    Seconded.

  601. Alex bangs the gavel

  602. moparisthebest

    out of curiousity has a vote ever resulted in a member not being renewed or accepted?

  603. Alex

    thanks everyone. Will update the lists tomorrow in the AM and send out the results to the lost

  604. dwd

    moparisthebest, Yes!

  605. Alex

    moparisthebest: yes

  606. Seve/SouL

    Congratulations everyone, good news

  607. moparisthebest

    how did that happen? do you just really annoy other members or what? :P

  608. Zash

    Other than the time nobody knew bears real name?

  609. dwd

    Zash, There was that, and, erm... Solaris? I can't think of the nickname he used.

  610. Alex

    bear is the famous one ;-)

  611. bear

    yes, I am the example everyone remembers about my membership being denied :)

  612. Seve/SouL

    bear: why so? (I do not know the story)

  613. Zash

    The tale

  614. bear

    the membership application didn't used to have a real name part, and I go by "bear" everywhere including email

  615. bear

    so when I forgot to update my application people properly didn't vote for me to stay as a member

  616. bear

    my application had "Mike Taylor" IIRC and some folks were not making the connection - trying to remember all of the details

  617. Seve/SouL

    bear: ohh I completely understand. I'm glad to know it went like this and not in a bad way heh :)

  618. Seve/SouL

    Thanks for explaining!

  619. edhelas

    I'm actually replying to some questions regarding XMPP on his thread, if you see some weird things do not hesitate to correct me https://www.reddit.com/r/opensource/comments/8myh78/movim_responsive_webbased_social_xmpp_client/