XSF Discussion - 2020-04-15


  1. apollonexpectus

    govanify =zosch@jabber.ru?

  2. apollonexpectus

    Zash =zosch@jabber.ru

  3. apollonexpectus

    ?

  4. apollonexpectus

    I started out as a 14 year old lesbian 10 years ago marginalized by society and bullied in school, the daughter of two diplomats i was well travelled and read at an early age and taught by some of the best minds in the world in the intricacies of bank account cashouts.*fraud boss of international crime see PGP for details look on masterlist ahmia.fi > masterlist ExpectUs Fraud Fullz Cashout Crime Boss Hansa WSM apollon nightmare

  5. apollonexpectus

    none of this was a bot i type fast and i cashout fast

  6. apollonexpectus

    πŸ™‚

  7. apollonexpectus

    πŸ˜‰

  8. apollonexpectus

    tftp 10.1.1.1

  9. apollonexpectus

    lol

  10. apollonexpectus

    --

  11. apollonexpectus

    '

  12. apollonexpectus

    select * from CASH where 'my bank account ' == > 1,000,000,000,000

  13. apollonexpectus

    πŸ™‚

  14. apollonexpectus

    select * from big_titty_bitches

  15. apollonexpectus

    select * from lesbians who love buttsex just like me

  16. tom

    Are there any working implementations of Jingle?

  17. Neustradamus

    rion: ^^

  18. Daniel

    tom: yes. What specifically are you looking for?

  19. tom

    Videocalls

  20. tom

    On linux

  21. tom

    Without a web browser

  22. tom

    https://upload.nuegia.net/adde0e10-bf17-487b-be96-afb7fc6ec6dc/qsbti5vpk9841.jpg

  23. Holger

    tom: https://desktop.jitsi.org

  24. Mr.eslamo

    Hi, is anyone has a book for xmpp starters ?

  25. Kev

    http://shop.oreilly.com/product/9780596521271.do is still the best option, I believe (author).

  26. edhelas

    ⭐ ⭐ ⭐ "Must Read" The Daily XMPP - 2009

  27. Zash

    Kev, not time for a n++th edition yet? :)

  28. Kev

    Zash: There are definitely interesting new things to say, although it feels like we're on the cusp of there being pretty much a whole new story about how one works with XMPP, and doing anything before that would be premature (even if we and O'Reilly were motivated to do another edition - I hate writing ;)).

  29. Mr.eslamo

    Thank you all, I hope if you have any advice in this technology i'm new here in this field and I hope to make good things with it

  30. Zash

    I remember http://shop.oreilly.com/product/9780470540718.do being pretty good, but not sure how well it has aged, with how fast the web has moved

  31. edhelas

    Mr.eslamo maybe https://xmpp.org/about/ could help

  32. Zash

    MattJ: Modern XMPP - The Book? 😝️

  33. MattJ

    When "Modern XMPP" exists, I think that would be sensible

  34. edhelas

    if you want to understand the basics, I think the best is to open a XMPP console and start to play with it :)

  35. MattJ

    flow, you wrote on the list that you would review MAM (thanks for the diffs btw) - do you plan to give any feedback?

  36. MattJ

    otherwise I plan to request merging soon after addressing the existing feedback

  37. Mr.eslamo

    Zash: Thank you, I will purchase this book and I'll start using it because I have ZERO knowledge about this technology πŸ™‚

  38. Daniel

    > if you want to understand the basics, I think the best is to open a XMPP console and start to play with it :) And read the rfc

  39. Daniel

    People always under estimate rfcs

  40. Kev

    Zash: I think the issue with that one is that stanza.io is mostly unmaintaned now, isn't it?

  41. Kev

    Now that Jack The Moffit doesn't XMPP anymore.

  42. Zash

    Wasn't it using Strophe.js?

  43. Zash

    That's still around afaik

  44. MattJ

    I think you mean strophe.js? And that's maintained

  45. Kev

    Sorry, yes, I'm getting names muddles.

  46. flow

    MattJ, I plan(ed) to. But I think you can take the silence as "mosly lack of disagreement" on the proposed changes

  47. Zash

    I could check if I just reached like an inch further up my bookshelf

  48. MattJ reacts to flow's message with :thumbs_up:

  49. flow

    MattJ, I plan(ed) to. But I think you can take the silence as "mostly lack of disagreement" on the proposed changes

  50. Zash

    Yup, Strophe.js and jQuery.

  51. Zash

    > Re: [Standards] OMEMO:2 Spec Sprint I read "OAuth2 Spec Sprint". :/

  52. MattJ

    Not yet

  53. MattJ

    Daniel, XEP-0333 in MUC: https://github.com/xsf/xeps/pull/927

  54. MattJ

    and whoever was in the conversation about 333 status code in MUC: https://github.com/xsf/xeps/pull/926

  55. MattJ

    (333 is purely a confusing coincidence)

  56. Zash

    It says status code 307?

  57. MattJ

    307 is what has been removed (from the examples)

  58. Zash

    Nice ellipsis Github, thanks

  59. MattJ

    The examples were suggesting that a server would send 307 + 333 together

  60. MattJ

    But it only makes sense to send one or the other

  61. MattJ

    Unless you want legacy clients to make it look like people keep getting kicked from the room

  62. jonas’

    I wanted that :>

  63. MattJ

    I assumed it would be pep. ;)

  64. pep.

    Saying things on me while I'm away!!

  65. pep.

    I'll have to look into poezio code again, not sure how I did that

  66. Daniel

    MattJ: when parsing a marker do I have to check both - if the ID matches stanza-id and normal. Or do I switch over depending on the availability of the stanza id namesapce on the room

  67. flow

    depending in the stanza-id feature availability, i'd say

  68. flow

    as you can only trust <stanza-id/> it a 'by' value of the MUC's bare JID, if that JID announces the stanza-id feature, and hence announces that the MUC will prevent stanza-id spoofing

  69. Daniel

    Yes I agree

  70. Daniel

    The same goes for adding it imho

  71. Daniel

    Currently the text says if there is a stanza id

  72. Daniel

    I think that should be changed to read if the feature is announced

  73. Daniel

    Then you can follow the same rule for sending and receiving

  74. MattJ

    Sounds sensible

  75. MattJ

    > Therefore, if a MUC announces support for &xep0359; and a &lt;stanza-id&gt; element is present within a markable stanza with a 'by' attribute matching the MUC's bare JID, this is the id that MUST be used when returning chat marker updates.

  76. MattJ

    ?

  77. MattJ

    Daniel, not sure if I understand your point about sending vs. receiving (do you mean sending == adding <markable>, receiving == responding with <received/>?)

  78. Daniel

    MattJ: no I mean the decision on whether or not to use the stanza id (over the message ID) is the same on all sides

  79. MattJ

    Hmm, right

  80. Daniel

    The one who sends out the displayed and the one who receives it

  81. MattJ

    Should usage within a MUC that doesn't advertise stanza-id be discouraged?

  82. Daniel

    Maybe

  83. Daniel

    I think reactions will do that

  84. MattJ

    Also what if a client adds <markable> to a message that the MUC doesn't archive?

  85. Daniel

    I'd be OK with it not working in those cases

  86. MattJ

    <p>Therefore, if a MUC announces support for &xep0359; then clients MUST always use the MUC-assigned id for Chat Markers. The id will be contained in a &lt;stanza-id&gt; element inserted into the stanza with a 'by' attribute matching the MUC's own JID.</p>

  87. MattJ

    <p>As per XEP-0359 security considerations, clients MUST only trust a &lt;stanza-id&gt; element with a 'by' attribute that matches the MUC's own JID, and MUST ignore any such element in MUCs that do not announce XEP-0359 support.</p>

  88. Daniel

    That sounds reasonable

  89. MattJ

    Updated the PR

  90. flow

    Daniel> I think that should be changed to read if the feature is announced that would be redundant to what the stanza-id xep already says

  91. MattJ

    Not really

  92. flow

    I am usually against XEPs repeating what other XEPs already say, but I see that there could be exceptions to that rule

  93. flow

    MattJ, how not really?

  94. MattJ

    Of the two paragraphs above, the first one applies to Markers only ("if the feature is present, the behaviour of your Markers implementation changes like this:")

  95. MattJ

    The second paragraph is duplicating what XEP-0359 says, but I chose to do that as it's calling out security stuff

  96. MattJ

    There is a high chance that someone implementing Markers would accidentally overlook that

  97. flow

    yep, hence I said that there could be exceptions to that rule

  98. flow

    but those really should be scarse

  99. flow

    MattJ, "MUST only trust" does not sound right, you could trust other <stanza-id/>'s too

  100. MattJ

    Alternative suggestions welcome, I changed that several times

  101. flow

    that is nitpicking, but I think that paragraph could become a blueprint for other <stanza-id/> using XEPs

  102. flow

    and we usually write empty elements, so instead of <stanza-id> XEPs typically use <stanza-id/>

  103. flow

    MattJ: As per XEP-0359 security considerations, clients MUST only trust a <stanza-id/> element with a 'by' attribute that matches the MUC's own JID, if the MUC's own JID announces XEP-0359 support.

  104. MattJ

    I had something like that, but didn't want it to sound like "If the MUC's JID announces support, you most only trust 'by' with the MUC's JID"

  105. MattJ

    i.e. if the MUC doesn't announce support, trust any

  106. flow

    hmm, maybe additionally specify that the stanza-id shouldn't be trusted if the support is not annouced?

  107. flow

    "If XEP-0359 support is not annoucned, then <stanza-id/> elements with a 'by' attribute that matches the MUC's own JID should be considered spoofed and be ignored

  108. flow

    "If XEP-0359 support is not annoucned, then <stanza-id/> elements with a 'by' attribute that matches the MUC's own JID should be considered spoofed and be ignored"

  109. flow

    something like that

  110. MattJ

    Yep, that sounds better

  111. MattJ

    How's this?

  112. MattJ

    <p>As per XEP-0359 security considerations, if XEP-0359 support is not announced then &lt;stanza-id/&gt; elements with a 'by' attribute that matches the MUC's own JID should be considered spoofed and MUST be ignored.</p>

  113. MattJ

    s/matches/match/

  114. flow

    like it

  115. flow

    ahh, hmm, maybe specifiy where the xep359 support is announced?

  116. flow

    just to make it bullet proof

  117. flow

    "is not annoucned on the MUC room's bare JID"

  118. flow

    i'd probably s/MUC's own JID/MUC room's JID/, but that could just be me

  119. MattJ

    Pushed

  120. sss

    Hey all

  121. sss

    any one online here ?

  122. tom

    Anything other than Jitsi that can do videocalls?

  123. Zash

    There's a bunch actually. Telepathy based things, Pidgin(β€½), Gajim, a few others. Atalk I heard.

  124. Zash

    I had a phone running Linux 10 making voice/video calls over XMPP 10 years ago.

  125. Zash

    I had a phone running Linux making voice/video calls over XMPP 10 years ago.

  126. Maranda

    Gajim not on Windows right?

  127. pep.

    Movim also

  128. pep.

    Gajim I don't think so no. Audio might work though