XSF Discussion - 2020-01-12


  1. jonas’

    moparisthebest, Daniel just needs to vote "on-list"

  2. Holger

    Ge0rG: XEP-0280 #6.1 now says: > A <message/> is is eligible for carbons [...] if [...] it contains payload elements typically used in IM ... and then mentions Delivery Receipts and CSN. I guess those two are meant to be examples rather than an exhaustive list? Then again, not having a definitive list might reduce the value of the guarantee #6.2 is trying to give for carbons:rules:0, no?

  3. Holger

    Apart from that, I guess this rule should mention that it still only applies to type={chat,normal}?

  4. Daniel

    we should really follow up on im routing 2

  5. jonas’

    Daniel, implementations are where it’s at at the moment, I think

  6. Ge0rG

    Holger [12:22]: > ... and then mentions Delivery Receipts and CSN. I guess those two are meant to be examples rather than an exhaustive list? Then again, not having a definitive list might reduce the value of the guarantee #6.2 is trying to give for carbons:rules:0, no? You are right in those points. I'd love to have an exhaustive list of "IM payloads", but that means significant effort to compile it

  7. Ge0rG

    Holger [12:23]: > Apart from that, I guess this rule should mention that it still only applies to type={chat,normal}? I'm not 100% sure on that.

  8. Daniel

    are there any known problems with im routing ng?

  9. dwd

    Daniel, No, although that's primary because nobody's tried to implement it yet AFAIK.

  10. jonas’

    I think I sent some feedback to the list, not sure if that was addressed. but it’s all theoretical at the moment

  11. dwd

    Daniel, No, although that's primarily because nobody's tried to implement it yet AFAIK.

  12. Daniel

    it seems way easier than adding to an endless list of rules and exceptions to carbons

  13. Daniel

    or maybe i'm missing something…

  14. jonas’

    it’s still a bit unclear how IM Routing 2.0 and non-2.0 domains interact

  15. Holger

    Ge0rG: I guess clients don't really want to receive carbons of outgoing 0184 receipts?

  16. jonas’

    I’m not sure about that

  17. dwd

    Holger, They don't?

  18. Holger

    *requests*

  19. Holger

    Dammit.

  20. jonas’

    ah, requests makes sense

  21. Holger

    Sorry.

  22. Daniel

    well requests are tied to actual messages?

  23. dwd

    Still not sure I understand.

  24. Holger

    Ah.

  25. Daniel

    and they are getting those anyway?

  26. dwd

    (What Daniel says)

  27. Holger

    Yeah, ignore me, thx.

  28. dwd

    We could, of course, just drop a "<traditional-im xmlns='...' this-message-is-for-im='boolean/>" into every message.

  29. Daniel

    i'm not sure what i would do with copies of outgoing receipts though

  30. Daniel

    but in the interest of making things simplier on the server i'd just ignore them

  31. Holger

    Yeah I can't think of a use-case either but I'd prefer to avoid even more special-casing unless there's a strong reason to do so.

  32. Ge0rG

    Daniel: copies of outgoing receipts tell you that you don't need to send a receipt any more

  33. Holger

    Ge0rG: You're not sure whether type={chat,normal} needs mentioning or whether the rule should only apply to those? Dunno about headline but you certainly don't want to apply the rule to groupchat, no?

  34. Ge0rG

    Daniel: I'm using that in MAM sync to reduce the number of receipts to send after sync

  35. Ge0rG

    Holger: message types are a mess

  36. Ge0rG

    Holger: I agree on groupchat though, and I suppose we need to make headline ephemeral+no-store

  37. Daniel

    > it’s still a bit unclear how IM Routing 2.0 and non-2.0 domains interact Maybe routing ng needs to honor no-copy and maybe private (the latter would be weird). Other than that I don't see any big interop problems

  38. Daniel

    Ge0rG: for mam agreed. Conversations will do that as well

  39. Daniel

    For live messages you will race anyway

  40. Ge0rG

    Daniel: yeah, can't do anything about that

  41. Ge0rG

    Except maybe on 0198 resume

  42. Daniel

    I think I might even have code for sm resume. But meh

  43. dwd

    Could it be that IM Routing 2.0 is just a tidied-up Carbons without the cCarbon wrapping?

  44. Daniel

    I wouldn't optimize for that

  45. Daniel

    dwd: yes. That's why writing clients and servers should be fairly easy

  46. Daniel

    Recycle existing code and get rid of the rule mess

  47. Daniel

    Unless I'm missing something major

  48. Daniel

    Plus it always reflects

  49. Ge0rG

    dwd: we still might need the wrapping for outgoing Carbons

  50. Daniel

    Which is a good thing imho

  51. Ge0rG

    OTOH, we don't get that in MAM

  52. dwd

    I don't think you can do without wrapping of some kind for reflection, can you?

  53. Daniel

    If you require clients to include origin ids you could

  54. Ge0rG

    Daniel: what for?

  55. Daniel

    If you wanted to optimize things further you could have the reflection strip out everything but the origin id and the server added elements

  56. Daniel

    Ge0rG: to identify a reflection

  57. Ge0rG

    You can identify a reflection on from being your JID and to being a different JID

  58. Ge0rG

    Daniel: just use message @id for that?

  59. Daniel

    That could also be a message from another client

  60. Daniel

    Ge0rG: same same

  61. Daniel

    (but different unique Ness properties)

  62. Ge0rG

    Daniel: your reflection will have your full JID as the from

  63. Ge0rG

    Daniel: we can finally fix @id uniqueness for IM 2.0

  64. Daniel

    (but then again im routing could also require uniqueness)

  65. Daniel

    Ge0rG: will it?

  66. Ge0rG

    Daniel: what else should be the from?

  67. Daniel

    Not saying should. But it could be the bare jid

  68. Daniel

    In any case I think the story is that we can make that work without wrapper

  69. Ge0rG

    I mean we can just embed everything into forwarded, but why?

  70. Holger

    What about (direct) MUC invitations? Carbon-copy only incoming?

  71. Ge0rG

    Holger: do invitations to self count as incoming?

  72. Holger

    Yes.

  73. Ge0rG

    Sounds good then

  74. jonas’

    FWIW, the IM-NG discussion also brought up the notion that full-jid messages are ephemeral (non-archived) by default, while bare jid messages are persistent (archived) by default

  75. eevvoor

    Ge0rG, any comments on the proposal? We submit it tonight.

  76. eevvoor

    plus flow and DebXWoody

  77. eevvoor

    Thanks to emus, everyone found your idea for inviting an AI-expert to the XMPP-Sprint extremely good. So we added that.

  78. jonas’

    AI-expert?

  79. eevvoor

    We will hand in a research proposal tonight with some AI stuff. So emus idea was to add that to the planned XMPP-sprint to. jonas’

  80. jonas’

    what kind of AI stuff?

  81. eevvoor

    I can send you the proposal in case you are interested,

  82. jonas’

    I’d like a two-line summary instead

  83. eevvoor

    It is machine translation and language learning with XMPP clients.

  84. jonas’

    ok, thanks

  85. eevvoor

    oneliner ;-P

  86. emus

    Many scucess for your proposal!

  87. eevvoor

    Thank you very much :).

  88. eevvoor

    Thank you very much :). emus

  89. neshtaxmpp

    mpparisbest

  90. neshtaxmpp

    do you know something new sslh.

  91. neshtaxmpp

    https://wiki.mattrude.com/SRV_records_for_XMPP_over_TLS is thia gonna gelp

  92. Daniel

    help for what?

  93. neshtaxmpp

    ssh show localhost in apache

  94. moparisthebest

    neshtaxmpp: the only thing I'm gonna say about it is the option you are looking for is https://github.com/yrutschle/sslh/blob/master/doc/config.md#transparent-proxy-support and there are great docs there

  95. neshtaxmpp

    moparisthebest: again the same ?

  96. moparisthebest

    It's the only thing to say so yes

  97. neshtaxmpp

    maybe we didnt sprak woth you from 1 year... and the same old depreceated doculentations that lie.

  98. neshtaxmpp

    ri tbink to try tgis: https://wiki.mattrude.com/SRV_records_for_XMPP_over_TLS

  99. neshtaxmpp

    is ot gonna sgow real ip ?

  100. moparisthebest

    The official docs are correct, I'm not going to review some other docs for correctness

  101. neshtaxmpp

    moparisthebest: the old are incorrect. they dont show how to 127. can be solved...

  102. moparisthebest

    Nope they are up to date and you are wrong, now seriously I'm not discussing it anymore

  103. neshtaxmpp

    i speak woth developer and he comment use iptables... it is danger... as newbies... dont want touch it

  104. neshtaxmpp

    moparisthebest: you are wrong. if im writing you again ot is becouae. 127 ia not solved.

  105. moparisthebest

    neshtaxmpp: wait lol did you just say you talked to the dev who said you must use iptables but don't want to use iptables? Hahaha

  106. moparisthebest

    You have to if you want it to work, just like the docs I linked say, it works and I know it because it works on my machine

  107. pep.

    (that's usually not the only sign to look for proof of work though, but nvm :p)

  108. moparisthebest

    Yes well everyone else's machines also who follows the simple instructions :)

  109. moparisthebest

    Not people who go "but I want to skip parts and have it still work" though

  110. neshtaxmpp

    moparisthebest: you are wrong, now seriously I'm not discussing it anymore

  111. moparisthebest

    Excellent