XSF Discussion - 2018-03-07

  1. jonasw

    {xep 155}

  2. Bunneh

    jonasw: Stanza Session Negotiation (Standards Track, Draft, 2016-01-20) See: https://xmpp.org/extensions/xep-0155.html

  3. Zash

    Are we devs going to drown in CFEs now?

  4. peter

    Yes, you are!

  5. jonasw

    Zash, first the editors are going to drown in CFEs ;-)

  6. Ge0rG

    Yay, I've got another change into XEP-0045! Two more and I've fixed it sufficiently to not need MIX any more! 🙌

  7. Kev

    I'm not convinced :)

  8. Kev

    Well, I guess if you switch it to work on bare JIDs, make occupancy persistent, synched with the user's server, and then add pubsub nodes you'd be most of the way there. You'd also have MIX.

  9. jonasw

    Kev, MIX doesn’t really sync with the users server or does it?

  10. jonasw

    IIRC MIX does not handle s2s link downtimes

  11. Kev

    The state of which rooms you're in does.

  12. Ge0rG

    jonasw: MIX contains strong words about ensuring consistency over s2s failures, but no hints for implementations on how to actually achieve that.

  13. jonasw

    something something s2s SM

  14. Ge0rG

    I'm really curious to see that play out in the wild.

  15. Ge0rG

    I've got popcorn and spectator seats.

  16. Ge0rG

    I might not even veto MIX in case it comes in fast enough

  17. daniel

    Ge0rG: that popcorn will be pretty stale by the time mix gets implemented

  18. Ge0rG

    daniel: touché

  19. SamWhited

    well played…

  20. lovetox

    Servers MUST NOT include the <stanza-id/> element in messages addressed to JIDs that do not have permissions to access the archive, such as a users’s outgoing messages to their contacts. However servers SHOULD include the element as a child of the forwarded message when using Message Carbons (XEP-0280) [3]

  21. lovetox

    why is this a SHOULD?

  22. lovetox

    this makes the whole reason we have mam:2 useless

  23. moparisthebest

    how do we go from "I made this strange but useful-to-me thing by tying 3 different proprietary silos together" to "I made this strange but useful-to-me thing with XMPP" ?

  24. moparisthebest


  25. moparisthebest

    is it that they don't know about XMPP or is it just shinier to use proprietary silos?

  26. Ge0rG

    moparisthebest: it's because there are more people who know http than xmpp, and because xmpp just lacks the right abstraction layer for IoT

  27. SamWhited

    No, it's because it's infinitely easier to use proprietary silos that have good support and nice HTTP APIs.

  28. SamWhited

    (too late; what Ge0rG said)

  29. moparisthebest

    all that looks way harder than how I'd probably do it, but meh

  30. fippo

    all xmpp needs is lots of dev advocates who write about poop buttons...

  31. Zash

    how will the poop button developers get paid?

  32. SamWhited

    true story; fippo ++

  33. waqas


  34. jonasw

    Zash, shitty

  35. waqas


  36. moparisthebest

    I've done similar things but I guess they just aren't fancy and I don't blog about them

  37. waqas

    I'm curious about how well emojis work in non-desktop XMPP clients

  38. Zash

    moparisthebest: Do things and talk about them.

  39. jonasw

    waqas, mobile you mean? pretty well

  40. SamWhited

    I'd think they would work better than on the desktop ones, no?

  41. Link Mauve

    waqas, in console it just works, if you have a recent enough glibc and a font.

  42. moparisthebest

    like when the amazon buttons came out, when you pushed it it sent out an ARP request, and I called sendxmpp

  43. Zash

    waqas: Better than on desktop probably

  44. moparisthebest

    but it's trivial, does that stuff require writing about?

  45. SamWhited

    On the more tightly controlled mobile system you presumably have nice built-in fonts for it and support in the application platform.

  46. jonasw

    need to figure out how to load my own font into QWebEngineView >.>

  47. waqas

    Zash: I was also thinking of CLI clients, do those actually show emojis well? I'd expect font issues

  48. Link Mauve

    waqas, yes.

  49. SamWhited

    moparisthebest: the problem with that statement is two fold: 1) it's probably not trivial for most people, 2) it's not about things being difficult, we don't need people to blog about difficult or complex things as much, we want to show that you can do things simply, so if it is actually trivial (or at least simple), blog away!

  50. jonasw

    waqas, https://sotecware.net/images/dont-puush-me/KmzOKUa0WA5-e_lLWT5Bx0s9lYxOaSOtqLcl1_tTv18.png

  51. SamWhited

    Interesting, simple projects are what attract people who will spend a weekend doing it. If it's not trivial, most likely no one wants to waste too much time on it.

  52. Zash

    waqas: https://www.zash.se/upload/3sakjSXMvw0y.png

  53. Link Mauve

    waqas, https://linkmauve.fr/files/wayland-screenshot-2018-03-07_21-39-01.png

  54. Link Mauve

    Ah, too late.

  55. moparisthebest

    I have a blog, but my last blog post was about new blog software on april 24th 2013 lol

  56. Zash

    Tho my screenshot has Ge0rGs plugin

  57. moparisthebest

    and the last one before that was a guest blog poster in 2006

  58. moparisthebest

    super active, in other words

  59. SamWhited

    my terminal is not that fancy :( https://i.imgur.com/SF16kJf.png

  60. Ge0rG

    fippo: what we need is a compelling abstraction layer with appropriate libraries. Something where you define your sensors and actors in a human readable way, eg. "button, two-state", "230V relais", and then those objects automatically log into your private server and you can define rules like "button DEADBEEF triggers relais FOOBAR"

  61. moparisthebest

    that sounds like a tool you build using something like xmpp in the background

  62. SamWhited

    That seems a bit specific to IoT (I don't disagree, but I'd start with decent, well-documented libraries in a number of popular languages that hide the XMPP specifics from you as much as possible…)

  63. moparisthebest

    in general I'd say that's too much overhead and too restrictive

  64. moparisthebest

    but it seems like what all these proprietary APIs do, so maybe it's what people want

  65. Ge0rG

    fippo: what we need is a compelling abstraction layer with appropriate libraries. Something where you define your sensors and actors in a human readable way, eg. "button, two-state", "230V relais", and then those objects automatically log into your private server and you can define rules like "button DEADBEEF triggers relais FOOBAR"

  66. Ge0rG

    SamWhited: yes, that's very specific to IoT, but it's something that we need to differentiate over MQTT, CoAP and other contenders

  67. lovetox

    this call to experience

  68. lovetox

    should only people answer that implemented the xep fully?

  69. Zash

    It's kinda like Last Calls

  70. lovetox

    or is it in general of interest what parts are used for which use case in clients?

  71. Zash goes to read what the posts actually say

  72. SamWhited

    lovetox: why you didn't implement it or why you only partially did would be useful too.

  73. SamWhited

    use cases are great

  74. lovetox

    k thanks

  75. Zash

    If you feel that you can answer any of the questions then that's surely useful info.

  76. jjrh

    https://news.ycombinator.com/item?id=16536254 'Slack' turning off their irc and XMPP gateways :p

  77. Zash


  78. Link Mauve

    Or how walled gardens first expose standard protocols to get the nerd crowds to root for them, and once they obtain some critical mass stop with that.

  79. ThurahT

    who needs/use slack anyway...

  80. ThurahT

    matrix otoh is somewhat useful.

  81. ThurahT

    still <3 XMPP.

  82. Link Mauve

    ThurahT, a few millions of users, at least.

  83. waqas

    The answer to "who needs/use slack" is a fairly large set of organizations :)

  84. ThurahT


  85. Link Mauve

    I’ve had to use it for a client.

  86. Zash

    waqas: You gon' have fun now?

  87. waqas

    My company uses it. There's quite a bit in the UX that I wish XMPP clients had.