XSF Discussion - 2019-06-10


  1. jubalh

    are there different ways to joina MUC?

  2. jubalh

    We have this issue: https://github.com/profanity-im/profanity/issues/1120

  3. jubalh

    And I don't quite understand why Profanity is able to autojoins on two test channels on my server, but not on the channel at dismail

  4. jubalh

    all channels are public and not password protected

  5. MattJ

    There are two ways to join a MUC, the ancient way and the correct way

  6. MattJ

    Prosody recently stopped accepting the ancient way

  7. MattJ

    May be related, or may not

  8. jubalh

    the issue only happens on reconnect after connection loss. otherwise it joins just fine

  9. Zash

    The ancient way gets confused for a status update easily, which often results in weirdness on reconnect.

  10. jubalh

    could it still be related?

  11. jubalh

    are both ways described in https://xmpp.org/extensions/xep-0045.html ?

  12. MattJ

    Yes, it could still be related, if profanity isn't actually rejoining the room but just sending a presence update

  13. jubalh

    i think it does that :)

  14. jubalh

    where can i read about how to do it right?

  15. Zash

    Used to be that the wrong way was the first thing you saw if you went to the 'Entering a Room' section.

  16. MattJ

    You would know if in the rooms it "successfully" rejoins you often have people missing from the occupant list, for example

  17. MattJ

    https://xmpp.org/extensions/xep-0045.html#enter is how to do it correctly

  18. jubalh

    thanks guys

  19. jubalh

    the channels that work use prosody 0.10.3 btw, does this still support the "old way" ?

  20. jubalh

    0.10.2 sorry

  21. MattJ

    Yes, it was dropped in 0.11.x

  22. jubalh

    alright, thanks!

  23. Zash

    Where a status update can get confused for a join just as easily as a join gets confused for a status update.

  24. goffi

    Hi, https://www.reddit.com/r/freesoftware/comments/by4ipr/android_now_forces_apps_to_include_proprietary/ ==> it will be a problem with GPL clients, which means, if I'm not mistaken, all OMEMO clients.

  25. pep.

    yeah. Conversations already deals with that apparently. As in, they don't buy-in and they're flagged as "inefficient battery usage"

  26. pep.

    So that they get bullied by their users I guess

  27. flow

    ralphm, could you add the blog's of our GSoC students to planet.jabber.org? Thee feed links are listed at https://wiki.xmpp.org/web/GSoC/2019/Accepted_Projects

  28. ralphm

    What is hrxi's full name?

  29. pep.

    Oh, could you also add me while you're at it, please :) Maxime Buquet / https://bouah.net, I think I asked a while ago

  30. ralphm

    pep.: done

  31. pep.

    Thanks

  32. pep.

    ralphm, does that work properly?

  33. pep.

    The link on my name points to the planet

  34. ralphm

    I think it breaks on your link rel="self"

  35. ralphm

    that is really weird

  36. Zash

    Wait where's the feed?

  37. ralphm

    (the link, not that it breaks)

  38. pep.

    https://bouah.net/index.xml

  39. pep.

    <link rel="alternate" type="application/atom" href="https://bouah.net/index.xml" title="Grumpy pep." />

  40. Zash

    Firefox doesn't think there is a feed

  41. ralphm

    pep.: I mean the link in the atom feed

  42. pep.

    oh

  43. pep.

    hmm.

  44. Zash

    `<link rel="self" href="https://bouah.net/"/>` ?

  45. ralphm

    yeah, that's not ok

  46. ralphm

    because it is not true

  47. pep.

    That should point to the feed?

  48. ralphm

    yes, and also have a type

  49. pep.

    k, let me see how that works

  50. pep.

    Do I actually need this <link/>?

  51. ralphm

    You are not linking to the correct location for the atom feed

  52. ralphm

    also unsure why you want to include a link to the html rendering

  53. ralphm

    also the type should be application/xml+atom

  54. ralphm

    so many bugs in one thing

  55. pep.

    indeed

  56. ralphm

    flow: did you see my question above?

  57. pep.

    Okay, should be fixed!

  58. ralphm

    pep.: hmm, maybe it does need an alternate link

  59. ralphm

    (next to the fixed self one)

  60. pep.

    to text/html ?

  61. pep.

    Ok I added it manually for now if you want to test again

  62. Link Mauve

    pep., it’s application/atom+xml, not application/xml+atom.

  63. pep.

    oops. At least now it's fixed :)

  64. flow

    ralphm, I believe hrxi does not want his full name disclosed/mentioned, but I could ask if its an issue

  65. ralphm

    flow: oh.