XSF Discussion - 2018-11-14

  1. jonas’

    fun question: what happens when a remote entity sends me a stanza which is larger than my servers stanza size limit?

  2. Zash

    Excellent question

  3. Ge0rG

    It probably won't arrive

  4. Ge0rG

    Let's implement Path MTU Discovery

  5. Ge0rG

    I wouldn't be surprised if your server would close the stream as invalid, forcing the remote server to reconnect and to resend the stanza.

  6. Ge0rG

    ...ad infinitum

  7. edhelas

    then the server should delay the s2s reconnection gradually to prevent such infinite loop to happen

  8. jonas’

    Ge0rG, sure, it won’t arrive, but what happens?

  9. jonas’

    right

  10. flow

    jonas’, error response stanza? I don't think that this justifies a stream:error nor that current impl do that

  11. jonas’

    flow, RFC 6120 disagrees

  12. jonas’

    stanza size limit is one of the examples on when to use the policy-violation stream error (see 4.9.3.14. policy-violation)

  13. jonas’

    lovely example, too: C: <message to='juliet@im.example.com' id='foo'> <body>[ ... the-emacs-manual ... ]</body> </message> S: <stream:error> <policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> <stanza-too-big xmlns='urn:xmpp:errors'/> </stream:error> S: </stream:stream>

  14. jonas’

    > [ ... the-emacs-manual ... ]

  15. flow

    uhh that is indeed a gem I had missed all the years

  16. Ge0rG

    Yes, the emacs manual clearly is a policy violation

  17. flow

    but still I stand by my statement

  18. jonas’

    but RFC 6120 allows both: If a connected resource or peer server sends a stanza that violates the upper limit, the receiving server MUST either return a <policy-violation/> stanza error (Section 8.3.3.12), thus allowing the sender to recover, or close the stream with a <policy-violation/> stream error (Section 4.9.3.14).

  19. jonas’

    (see 13.12. Denial of Service)

  20. Zash

    What do we do?

  21. Ge0rG

    Crash

  22. moparisthebest

    hmm I didn't realize I hadn't had xmpp spam for months until I got 5 today...

  23. moparisthebest

    I suppose that is in some ways good

  24. Zash

    Classic human, doesn't know how good you have it until it gets worse

  25. Link Mauve

    moparisthebest, there is a huge IBR registration wave which started three days ago, so it’s no wonder it’s finally getting used.

  26. Link Mauve

    moparisthebest, please report to their server admin, domain registrar, IP provider, in this order.

  27. edhelas

    we had a nice article from a user about OMEMO published https://fr.movim.eu/?blog/debacle%40movim.eu/things-i-don-t-like-with-omemo-as-it-is-today-ogqaAM

  28. edhelas

    I'd be happy if some of you can reply to him about the points he mentionned

  29. Ge0rG

    I agree with those points.

  30. edhelas

    I'm also thinking of adding xCal (https://datatracker.ietf.org/doc/rfc6321/) to Pubsub items, next to the Atom elements, to be able to attach events

  31. Link Mauve

    edhelas, see https://xmpp.org/extensions/inbox/calendaring.html maybe.

  32. Link Mauve

    I never managed to figure out why it hadn’t been accepted.

  33. Zash

    Hmmm, http://logs.xmpp.org/council/ don't go back that far :(

  34. edhelas

    this is not based on the RFC 6321 (by Peter St Andre by the way) and rely on some server things

  35. Zash

    But I recall someone saying we shouldn't try to re-do calendaring, it's a complicated problem

  36. edhelas

    also it basically define a specific calendar node

  37. edhelas

    here I just want to append events to blog publication

  38. Zash

    Sticking calendar events in PubSub seems fine enough

  39. edhelas

    like you're doing when attaching .cal file to your emails

  40. Link Mauve

    Don’t you want notifications and such rather than just a dumb storage?

  41. Link Mauve

    Have a look at how iCal servers such as Radicale are doing it.

  42. edhelas

    well if you already suscribed to the node or following the JID you'll get notified by those events

  43. Zash

    Link Mauve: I recommend you don't if you value your sanity

  44. Zash

    iCal is very complicated

  45. Link Mauve

    Zash, I know, I’ve worked on that in the past.

  46. edhelas

    I'll give it a try, just create a small piece of UI to set a date, title, location when publishing a post

  47. Link Mauve

    edhelas, isn’t Atom enough for this purpose?

  48. Zash

    I've researched it. CardDAV is acceptable, but CalDAV is complicated madness

  49. edhelas

    Link Mauve Atom is not made for events

  50. edhelas

    rfc6321 looks fine to me

  51. edhelas

    and then Movim can generate .cal file out of it to import the events in the calendar applications

  52. Zash

    hmm http://activitystrea.ms/specs/json/schema/activity-schema.html#event

  53. edhelas

    maybe it's time to move to JSON

  54. Zash

    No

  55. Yagiza

    Not again!

  56. Zash

    Activitystreams has an Atom mapping, tho everyone's doing the JSON thing now

  57. Zash

    Anyways, there's prior art to look at

  58. flow

    I wonder if roster annotations isn't repeating the same mistake we did with presence extensions (regarding council@)

  59. jonas’

    huh?

  60. jonas’

    how are presence extensions a mistake?

  61. flow

    There was a time where everything stuffed into presence (tune, geoloc, …), which eventually leaded to the invention of PEP and +notify

  62. jonas’

    right

  63. jonas’

    what alternatives are there, though?

  64. jonas’

    make the server put it in PEP, too?

  65. jonas’

    (instead of annotating the roster) ✎

  66. jonas’

    (instead of annotating the roster directly) ✏

  67. rion

    one should remove presences from xmpp and replace them with pep =)

  68. flow

    Possibly, maybe there are other alternatives, maybe a caps like mechanism would be sensible. I haven't given it much thought, as people already started annotating the roster

  69. jonas’

    flow, only mix annotates it, right?

  70. jonas’

    MIX also has some .. special requirements because they want to hide the MIXes from clients which don’t understand MIX

  71. jonas’

    so I don’t think that’s a good precedent in general

  72. flow

    Well I wouldn't rule it out that there are other XEPs (and ProtoXEPs) burried which also it

  73. jonas’

    protoxeps don’t count

  74. flow

    Help me here, MIX annotating was a <mix/> element to the roster <item/>, right? How does that help with hiding anything?

  75. jonas’

    you only get it when you ask for it

  76. flow

    jonas’, you don't happen to have a pointer to the relevant section of the MIX spec at hand?

  77. jonas’

    (*shaking fist at mozilla for taking away the possibility to disable ctrl+q)

  78. jonas’

    flow, https://xmpp.org/extensions/xep-0405.html#mix-roster-capability-sharing

  79. flow

    jonas’, thanks :)

  80. flow

    Hmm, what if another client of mine adds a MIX channel, does the roster push contain <channel/> or not?

  81. flow

    Or isn't there a roster push send?

  82. flow

    How about the server queries the client's disco#info before the first roster operation and decides based on the resulting disco#info how the roster is presented, and sends additional stanzas with the related roster item information for optional features…

  83. jonas’

    that was discussed on-list

  84. flow

    great, or not great, because it was probably dismissed

  85. jjrh

    I was reading XEP-0409, not sure the problem it's trying to solve. Is the idea to allow new XEPs to eventually modernize routing for IM users and have IM-NG for legacy or specific use cases (like M2M )?

  86. flow

    jjrh, the problem is that current rfc6120/6121 routing rules are unnecessarily complex, I'd say

  87. jjrh

    oh the part about carbons MUST NOT be enabled confused me, but I didn't read close enough - the server will reflect the message to all my IM-NG resources so i'll see my own messages.

  88. Ge0rG

    The current rules are complex and insufficient for a reality where a user has multiple clients

  89. Ge0rG

    But we can't just change them because it might break current use cases outside of IM, and Carbons and MAM are not sufficient because they are just hacks on top of the bad rules.

  90. Ge0rG

    Somebody gave a talk at the February 2018 Summit about what needs fixing, and IM-NG was the resulting specification

  91. Ge0rG

    jjrh: https://op-co.de/tmp/whats-wrong-with-xmpp-2017.pdf

  92. jjrh

    Cool thanks

  93. Ge0rG

    flow: sorry, but I'm being evil to you.

  94. Ge0rG

    XEP-0359 needs to mandate that the stanza @id MUST (SHOULD) be the same as the <origin-id> @id

  95. flow

    hear hear

  96. Ge0rG

    flow: we had that discussion many months ago, and I didn't change my mind because you didn't bring up compelling arguments. Feel free to convinve me on list or just add that one sentence.

  97. flow

    I would be more interested if you envision a namespace bump or not

  98. Ge0rG

    flow: how many implementations are there? And how many don't set the two @id fields to the same value?

  99. pep.

    Holger, "Edit: Add point about OMEMO complexity and errors, thanks to Holger!" on debacle's article re OMEMO. Should we deprecate this one now? :-°

  100. pep.

    Also, "It does not work with local, serverless messaging. I don't use this feature a lot, but still, encryption should work with it, too." too bad, because that's actually one place where it would actually be useful

  101. pep.

    I guess "it works" if you already have keys

  102. pep.

    Just that clients don't allow that