XSF Discussion - 2018-09-19


  1. Zash

    https://xmpp.org/extensions/xep-0084.html#proto-data Why does it say > The XML character data MUST represent the image data for the avatar with a content-type of "image/png"

  2. Zash

    Are you not allowed to put other kinds of image data in <data>?

  3. jonas’

    no you’re not

  4. jonas’

    other images are supposed to be delivered via other means

  5. jonas’

    the pubsub thing is supposed to contain image/png always

  6. Zash

    That does not seem to reflect current usage at all

  7. jonas’

    yes

  8. jonas’

    it’s daniel’s fault

  9. daniel

    It's not my fault that the xep says png for no reason whatsoever

  10. Zash

    Not no reason, tho it is overly strict in restricting it to only PNG. JPEG and GIF are well-supported enough to be ok there.

  11. edhelas

    can't wait for animated gif

  12. Zash

    Please don't

  13. Zash

    Everyone has realized that GIF is a terrible video format by now

  14. Ge0rG

    Zash: but it's too entrenched.

  15. Zash

    Ge0rG: But "GIF" now means "looping audio-less video"...

  16. ralphm

    In your opinion, does/should XEP-0030 support unregistered values for Disco identities (category/type), possibly using Clark's Notation, and falling back to the registry for unqualified values (like XEP-0068 does)?

  17. MattJ

    Do you really have something that isn't already covered?

  18. MattJ

    or is this just a "I need to identify my thing" requirement?

  19. ralphm

    Well, the use case is different types of user accounts: regular people v.s. e.g. agents of a commercial entity.

  20. ralphm

    So for the former I can use account/registered, but for the latter, I'd need something new for the type field.

  21. ralphm

    And while I appreciate we have a Registrar function for this in general, having a capability to achieve distributed extensibility using Clark's Notation would be nice.

  22. ralphm

    MattJ: ^

  23. MattJ

    If you really think that's the best option for you, I don't think it's not allowed

  24. MattJ

    I meant, the XEP explicitly says it is "preferably" a registered identity

  25. MattJ

    *I mean

  26. MattJ

    and if you're going to go for something unregistered, Clark's notation makes sense

  27. Zash

    For me on my own self-hosted server, it's is a bit weird to call my account 'registered'

  28. Zash

    Tho there is also admin IIRC?

  29. ralphm

    Zash: the idea here is that you can see who's the admin of a server, so you'd probably have two identities: one with `registered` and one with `admin`.

  30. ralphm

    MattJ: right. Any other ideas?

  31. ralphm

    I'm probably _also_ going to add a Data Form (XEP-0128) for additional meta-data, but it felt wrong to put this information there, if there's the nice concept of identity already.

  32. MattJ

    ralphm, I think your approach seems fine, though if it's also a registered account I would include the standard identity also

  33. MattJ

    So clients can still get an idea of what it is, even if they don't recognise the non-standard one

  34. Zash

    There's also stuff you can stuff into the vcard for this kind of thing, altho that's a bit more directed towards human consumption

  35. ralphm

    MattJ: for sure

  36. ralphm

    Zash: well, vCard is kind a set in stone. It is not really extensible.

  37. ralphm

    Or at least our use of what became known as vCard-tmp

  38. Zash

    vcard4!

  39. jonas’

    ralphm, fwiw, I suggest to have account/registered *plus* the account/{private-namespace}agent tihng

  40. jonas’

    for compatibility

  41. Zash

    But I mean like the 'role' field

  42. ralphm

    jonas’: yes indeed, just like MattJ said :-D

  43. ralphm

    Zash: I guess. Still feels like a hack

  44. Holger

    Do clients ever change the list of PEP nodes subscribed via +notify filtering during a session? I mean if they didn't, servers wouldn't have to bother with caching the +notify caps and could just auto-subscribe based on the caps sent with the initial presence (or am I overlooking something?) ...

  45. MattJ

    Holger, "do they" vs. "could they"?

  46. Holger

    Well if they don't, 0060 could be adjusted. In theory.

  47. edhelas

    Holger I'm not doing it on Movim

  48. Holger

    I mean right now the design is "auto-subscribe the client to all open PEP nodes, then filter based on +notify". That's somewhat complex/expensive compared to "auto-subscribe based on +notify".

  49. Zash

    Prosody dynamically adds and removes subscriptions based on +notify

  50. Holger

    That's somewhat expensive as well ...

  51. Holger

    And right now the idea is that a client sending presence to a single contact on my server will change the behavior of all PEP nodes on my server, no? Though seems even less likely that clients will depend on that ...

  52. MattJ

    Can someone even explain to me the different between "auto-subscribe + filter w/+notify" vs. "auto-subscribe w/+notify"?

  53. MattJ

    *difference

  54. MattJ

    The XEP makes quite sure to get this point across, but what is the practical difference?

  55. Holger

    The server auto-subscribes on *initial* presence. Due to the filtering semantics, the server also needs to check all following presence.

  56. Holger

    How do you handle following presence that doesn't contain caps? Unsubscribe all PEP nodes? (Doesn't happen in practice?)

  57. Link Mauve

    ECaps2 adds the concept of sending the caps only on initial presence, the server advertising to the client it will add it on all subsequent presence changes.

  58. Link Mauve

    I don’t know of any server implementation though.

  59. Holger

    Also 0163 (though not 0060) says this in a footnote: "any subsequent presence stanza with no 'type' attribute that the PEP service receives after the initial presence notification but before the subscriber against goes offline MUST NOT trigger sending of a new pubsub notification."

  60. Holger

    So strictly speaking, if the server sees a CAPS change with a new +notify string, the node should be subscribed but the last item should not be sent? :-)

  61. MattJ

    I'm not a fan of our mod_pep, and can rarely figure out what it's doing - however from a glance I would say that we would unsubscribe if a future presence didn't contain caps

  62. Holger

    Ok, thanks. So then your solution to auto-update the subscription lists whenever you receive presence is probably no more complex compared to only doing it on initial presence indeed. But I'd really like to avoid checking all subscription lists on each and every presence :-/ Especially if clients never change their +notify lists anyway.

  63. Zash

    I do wonder if we should try to standardize filtering on the receiving end?

  64. Holger

    Haha. Now that I'm in the middle of another attempt of fixing ejabberd's PEP once and for good :-)

  65. Zash

    As in, with explicit negotiation instead of just sending all everything to everyone all the time

  66. edhelas

    Holger can you please fix ejabberd Pubsub once and for good at the same time ?

  67. Holger

    edhelas: But it's awesome already! You just need a webscale DB backend or something.

  68. Zash

    wobscale

  69. edhelas

    what about clustering SQLite on RPi instances ?

  70. Holger

    I think MongoDB is the one and only option.

  71. Holger

    Hm I'm undecided whether to ask standards@ if we can remove that requirement of checking subsequent presence for +notify updates.

  72. Holger

    Realistically there's zero chance of changing this in 0060 right ...

  73. MattJ

    If a client really did want to change its PEP subscriptions, it feels a bit wrong to force it to reconnect for that

  74. MattJ

    and what difference does initial vs. non-initial make, to the server?

  75. Holger

    I'm just concerned about load. I think clients sometimes send presence quite regularly ...

  76. MattJ

    Load on what?

  77. Holger

    CPU

  78. Holger

    Plus cluster sync.

  79. MattJ

    Ok

  80. MattJ

    so it's not a simplification, but an optimisation

  81. Holger

    Yes, if I buy your implementation.

  82. Holger

    Not sure I will, I can imagine a separate filtering step ending up being cheaper (though more complex) ...

  83. Holger

    I'm all for offering any functionality clients need, and if it's expensive, so be it. But if it's expensive and no client ever needs it, that's a bit annoying.

  84. MattJ

    I think the reality is that no, it will rarely (if ever in an IM client) change

  85. MattJ

    But it feels like a pretty awkward limitation to impose on the protocol

  86. MattJ

    just to save some CPU cycles

  87. MattJ

    I mean, I'd be ok if we found some way to say explicitly "yes, I want my subscriptions updated"

  88. MattJ

    But is it worth it?

  89. jonas’

    Holger, uh, a client may load a plugin during runtime which adds a +notify

  90. jonas’

    it would be awkward if that didn’t work until a reconnect

  91. Holger

    Hmmm :-/

  92. Holger

    Ok, I'll think about it a bit more. Thanks for your feedback.

  93. Holger

    jonas': Though I think spec-wise, at least 0163 #4.3.3 (2.) should be updated if you want to be sure that conforming servers work that way: https://xmpp.org/extensions/xep-0163.html#notify-when

  94. jonas’

    Holger, from my reading, the text only implies that you need to fetch the last item manually if you publish +notify in a non-initial presence

  95. Holger

    Ah yes you're right I guess.

  96. Holger

    Doesn't sound straightforward to me either though.

  97. Zash

    Holger, you got quite the set of role labels there, and they are *very* visible in Converse.js

  98. Holger

    Cool!

  99. Holger

    I feel special now.

  100. ralphm

    Steve Kille: I don't understand the requirement to specify node='mix' here: https://xmpp.org/extensions/xep-0369.html#disco-channel-info

  101. ralphm

    XEP-0030/XEP-0128 allow for multiple identities and associated disco extension forms. Also, how does the client know to use node='mix' _before_ it gets the disco identity?

  102. Steve Kille

    This is to support MIX and MUC on same node. To make this work, you need to have different info for MIX and MUC

  103. Link Mauve

    Andrew Nenakhov, what license is the Xabber logo? Would it be possible to upload it to Wikimedia Commons?