XSF Discussion - 2020-04-04

  1. Neustradamus

    Problem in the ML, like I have said here previously, two times for the same part "XEP-0363"

  2. bantumi

    good morning to everyone

  3. bantumi

    i have a problem

  4. bantumi

    anyone ca help me ? i can explain my issue ?

  5. pep.

    “Zash: not changing state” idempotent?

  6. Zash

    That's the word

  7. bantumi

    can i explain my issue ?

  8. Zash

    What's it about?

  9. pep.

    bantumi: don't ask to ask. I'm afraid you might not be at the right place though

  10. bantumi

    sorry, i'm creating a xmpp chat with iOS and Android app

  11. bantumi

    i implement everything

  12. bantumi

    on server i have ejabber installed

  13. bantumi

    but i have last issue with remote push notification for offline message

  14. bantumi

    since 2 weeks ago we use Openfire but we decide to switch to ejabber

  15. bantumi

    on openfire we use a plugin that redirect message to a serrver trought API and all works fine

  16. bantumi

    but now with ejabber i dont find any way to do the same things

  17. pep.

    what does that plugin do exactly? not sure I understand

  18. Daniel

    bantumi: ejabberd has support for xep-0357

  19. bantumi

    pep. this plugin is called "CallbackOnOffline" that send a json to another server with this format { "token":"21uh9d1h91d", "from":"user@mychatapp.com", "to":"user123@mychatapp.com", "body":"Message body, so what user's typed" }

  20. Daniel

    It should behave roughly similar only that the communication between the push server and the xmpp server is xmpp and not http

  21. bantumi

    and this other our server send the request to FCM that phisically send the push to device

  22. pep.

    bantumi: don't think that's standard is it

  23. bantumi

    Daniel i know but i dont understand how to send push notification to user

  24. pep.

    you can probably write your own ejabberd module that does about the same thing

  25. Daniel

    What you call 'our server' is called 'app server' in the lingo of 357

  26. Daniel

    So you have to rewrite 'your server' to be a 357 app server

  27. Daniel

    Or use some stock 'app server' like p2

  28. bantumi


  29. bantumi

    this ?

  30. Daniel


  31. bantumi

    you are the creator !!!??? great!

  32. bantumi

    can you help me install this module on my server ?

  33. bantumi

    i try today but i have some issue

  34. bantumi

    we have 3 server ....

  35. bantumi

    1- server xmpp with openfire that we want to leave

  36. bantumi

    2- server for user details

  37. bantumi

    2- server for user details based on windows

  38. bantumi

    3- debain server where now we install ejabber

  39. bantumi

    1- server xmpp with openfire that we want to leave based on windows

  40. Daniel

    If you look up my contact details on the internet and send me an email I can give you a cost estimate for commercial support for p2

  41. Daniel

    Otherwise reading and understanding the Readme and xep 357 should bring you a long way

  42. bantumi

    i send you an email

  43. bantumi

    email sent

  44. bantumi

    confirm me that you receive it

  45. Daniel

    bantumi: Got the email. Will respond to it later today

  46. bantumi

    thanks a lot

  47. Zash

    Did we ever discuss having the server send caps for its own local componends to clients during session startup?

  48. Daniel

    caps as in presence?

  49. Zash

    Caps as in the thing that's most often sent in presence, yes

  50. Zash

    It can also be found in <stream:features/> sometimes

  51. lovetox

    yes that would be useful, would spare a few disco info requests

  52. lovetox

    on startup

  53. Daniel

    i think we discussed a need for it

  54. Daniel

    not that particular solution

  55. lovetox

    was this not in entitycaps 2

  56. Zash

    Not from what I can see

  57. flow

    Zash, we did discuss

  58. eta

    what are the current standards in use for client nicknames?

  59. eta

    (I'm implementing a transport; I tried sending <nick> in presence subscription requests but neither gajim nor conversations seemed to care)

  60. Zash

    Oh boy

  61. Zash

    There's that, usually in PEP. And vCards. And in MUC it's its own thing using the resource.

  62. lovetox

    eta most clients support nicks via PEP

  63. lovetox

    so UserNickname XEP

  64. eta

    lovetox, but not the <nick/> fallback in that XEP?

  65. eta

    I'd ideally like to avoid implementing the whole of PEP just for nicknames in my transport

  66. lovetox

    i think Gajim respects the nick in presence on the subscribe

  67. lovetox

    so it shows nick wants to subscribe to you

  68. lovetox

    but dont think afterwards

  69. eta


  70. lovetox

    let me look through the code

  71. eta

    could I get away with just sending PEP events as demonstrated in XEP-0172 on nickname changes and not implementing the whole of PEP/

  72. eta


  73. Daniel

    Yeah I think it's the same in Conversations. It supports nicks in subscribe presences.

  74. Daniel

    And pep

  75. lovetox

    hm how does you transport add the contact

  76. lovetox

    do you maybe send a roster item exchange ?

  77. lovetox

    because that has a nickname attribute and this would be pushed to the roster

  78. eta

    lovetox, it sends regular presence subscribe

  79. eta

    I must be doing something wrong then; neither Conversations nor gajim seem to like my nick in presence subscribe :<

  80. eta

    my stanza looks like: <presence from="REDACTED@ig.theta.eu.org" id="71de7ae4-2dc4-4e69-9c2d-536474106c49" to="eta@theta.eu.org" type="subscribe"><status>I'm someone from your WhatsApp contacts! (via whatsxmpp)</status><nick xmlns="http://jabber.org/protocol/nick">eta</nick></presence>

  81. lovetox

    eta if you send a subscribe, a dialog in gajim pops up that says add this jid to roster

  82. eta

    lovetox, no it did that, just not with the nick

  83. lovetox

    in gajim 1.1.3?

  84. eta

    lovetox, reasonably fresh git, but conversations also didn't get the nick

  85. lovetox

    thats a bug then in Gajim

  86. eta

    does the stanza look okay to you?

  87. lovetox

    could be forgotten in the redesign of the dialog

  88. lovetox

    yeah looks fine

  89. eta

    if transports are supposed to use roster push, I can use roster push I guess

  90. eta

    but currently I haven't used any transport-specific APIs

  91. lovetox

    just leave it like that i take a look into Gajim codebase

  92. lovetox

    but i think this way works

  93. lovetox

    because if you propose the nick in the presence, we fill it on the user add to roster dialog

  94. lovetox

    and if the user accepts it, then the nickname is permanently in the roster saved

  95. lovetox

    to should be fine

  96. Ge0rG

    eta: you should just automatically add all transport contacts automatically, not let the user approve every one of them

  97. Zash

    eta: Make sure you're testing this with the client connected if you're using Prosody < trunk

  98. Zash

    Relevant: https://xmpp.org/extensions/xep-0144.html

  99. eta

    oh right, that looks like the thing I should be bothering with

  100. Zash

    also https://xmpp.org/extensions/xep-0321.html might be of interest

  101. eta

    how widely implemented is XEP-0144 though?

  102. eta

    I mean I know gajim does it

  103. eta

    but dunno about, say, conversations

  104. Zash

    I don't know

  105. eta


  106. eta

    I think it's still worth keeping the old "spam user with presence subscription" code then, no?

  107. Zash

    Hm, during transport setup you know the full JID of the user doing the thing, so you can find out via disco#info if they understand '144

  108. Zash

    And that's the point when there'll be a whole bunch of contacts to add at once

  109. Ge0rG

    0321 is how spectrum does it, right?

  110. Zash


  111. Zash

    If supported by the server (there's a prosody plugin).

  112. Ge0rG

    It had a great UX. Maybe just add support into conversations?

  113. lovetox

    144 is only good though on register

  114. lovetox

    afterwards if a legacy user adds you, then subscribe is probably better

  115. lovetox

    i think C understands 144 aswell

  116. Zash

    Has anyone other than Spectrum and Prosody (non-core module tho) implemented XEP-0321? @editors CFE mebbe?

  117. Guus

    Zash: Openfire does not.