jdev - 2022-01-10

  1. xnamed

    I'm confused about the wiki recent changes where I see membership applications for 2022 https://wiki.xmpp.org/web/Special:RecentChanges?hidebots=1&limit=50&days=7&enhanced=1&urlversion=2 but I don't see the applications list of 2022 here https://wiki.xmpp.org/web/Membership_Applications Can I apply now or I have to wait?

  2. Zash

    https://wiki.xmpp.org/web/Membership_Applications_Q1_2022 ?

  3. xnamed

    Thank you Zash

  4. xnamed

    Should I create my application page and name it My_Name_Application_2022 manually or it there is something else I'm missing?

  5. jonas’

    xnamed, I use User:NAME/Application_YYYY, where NAME is my wiki user name and YYYY is the year number

  6. jonas’

    so I don't pollute the global namespace with all that

  7. Ge0rG

    jonas’: given that you also apply for Council, some more namespacing might be appropriate ;)

  8. jonas’

    Ge0rG, User:NAME/Council_YYYY for that :)

  9. jonas’


  10. jonas’


  11. jonas’

    I didn't check

  12. Ge0rG


  13. edhelas


  14. xnamed

    Thank you jonas’

  15. junaid

    i've put up a simple webhook->xmpp solution at https://slickmsg.com/ ... I'm unaware of there existing any other one open to the public. i still have to create the privacy-policy and terms-of-service, but i've tried to keep everything simple and easy to use. i plan on creating a blog section with some guides on how eager users can setup their own similar solutions. please share comments/suggestions/improvements with me ... junaid@yax.im (i know it's ugly but I don't have any plan on making it pretty any time soon)

  16. jonas’

    possibly relevant: https://modules.prosody.im/mod_slack_webhooks.html

  17. junaid

    yip, there's quite a few way to implement similar. prosody alone has multiple plugins that could be used/abused to fulfil the requirement ... mod_post_msg , mod_rest, etc. majority of people just get accounts on established xmpp servers.. but are then left without an API/webhook system for automation/scripts. (API/webhook automation already established as core functionality for most other walled-garden platforms)

  18. MattJ

    junaid, this is excellent! It really needed to exist :)

  19. jonas’

    mmmmm, webhook.jabber.network? :)

  20. junaid

    MattJ 👍️ jonas’ that subdomain aint resolving for me, or is it a joke? in which case i prob need ☕️ refill

  21. jonas’

    junaid, it was a low-key offer that I could point that subdomain at your service if you wanted to rebase it to use that.

  22. junaid

    thanks for the kind offer jonas’. i'll keep a note of it. for now, i think let's first validate the idea before making long-term decisions. user adoption and potential for abuse are my main concerns. usability is also a concern but that will only be improved as more people use it and provide feedback.

  23. MattJ

    One suggestion I have is to reuse an existing API format (or better: multiple). That way you will have immediate support for lots of existing software/services.

  24. MattJ

    For example, Gotify would be relatively straightforward: https://gotify.net/api-docs#/message/createMessage

  25. junaid

    good idea and added to the TODO list. any other compat-API requests?

  26. nephele

    I've been trying siskin on iOS for some days now, it's not that useable... it keeps duplicating MUC messages countlessly :( is there some specific room to complain about iOS clients?

  27. jonas’

    Siskin feedback specifically would probably best addressed in the tigase MUC

  28. jonas’

    nephele, https://search.jabber.network/search?q=tigase+support -> xmpp:tigase@muc.xmpp.org?join

  29. nephele

    Oh neat, a room searcher... thanks :D

  30. edhelas

    jabber.network is the new Google

  31. nephele searches for "game dev" and finds a single room with one participant

  32. edhelas

    2 now :)

  33. lovetox

    in a non anonymous room prosody returns all the connected resources of the user

  34. lovetox

    is this something i can expect from other servers aswell?

  35. jonas’

    it's unspecified

  36. lovetox


  37. jonas’

    I know, right?

  38. lovetox

    probably also if full jid or bare jid

  39. jonas’


  40. lovetox

    so i can get, one bare jid, one full jid, or multiple full jids

  41. lovetox

    wonder if i should downgrade to one bare jid at lib level

  42. lovetox

    or pass on whatever i get, and let the app deal with it

  43. defanor

    I think it tends to be more annoying when a library (or any other information source) eats/strips the information you can use, rather than when it provides a bit more than needed.

  44. qy

    Applications too

  45. qy

    See also: most xmpp clients

  46. jonas’

    disagree for applications

  47. jonas’

    many users find too much information to be overwhelming

  48. lovetox

    as im in the position to write the lib AND the app, i find it in the app really anoying, if i cant depend on things. and always have to if/else everything

  49. lovetox

    especially if its something that is unspecified and only a few servers do, and may stop at any moment

  50. lovetox

    i rarley want to depend on such things as an App

  51. lovetox

    but as a lib, i parse everything into useful structs for the app, but i leave an escape hatch open as the app can always look at the stanza from which the struct was created

  52. qy

    Guess im just a diehard power user

  53. qy

    Hidden stuff rubs me raw

  54. jonas’

    qy, you are indeed

  55. jonas’

    (I am, too)

  56. junglebook


  57. junglebook


  58. jonas’

    I was about to say, this isn't about SMTP ;)

  59. xiantian


  60. qy


  61. Zash

    501 Syntax: EHLO hostname

  62. nephele

    heol ohtsanem