jdev - 2024-01-31


  1. goffi

    debacle: as stated above, it's useful for other sessions (say you publish on your phone, your desktop must be aware of the item).

  2. goffi

    specific behaviour could be done though, I may add this with an option in Libervia Pubsub.

  3. MattJ

    debacle: is the publisher interested in receiving the same kind of data published by others? Or is it only for publishing?

  4. flow

    debacle, this probably requires a protocol extension which specifies a node configuration option to not publish the item back to the publishing entity

  5. flow

    the issue is not limited to the subscription access model, everytime you are subscribed to a node to which you publish the notification to the publishing entity could be omited, since it is implicit with the IQ result response (as you rightfully noted)

  6. flow

    debacle, so if you are kewl with one of the developers of the XMPP pubsub service you use, you could ask them to hack something up for this and XEP it up

  7. flow

    MattJ, if I would guess I'd say that only one entity publishes to the node in debacle's case

  8. debacle

    MattJ Only publishing. It's always the IoT device publishing on its (multiple) own PEP nodes, other users are subscribed.

  9. debacle

    flow In fact, I'm talking to the developer of the XMPP server right now about it. You know him ;-)

  10. flow

    debacle, say hi to him from me :)

  11. debacle

    It seems to be ... difficult. The pubsub service does not necessarily know, from which full JID the iq came?

  12. debacle

    We might try Roster Group subscription model. (There was a disadvantage about it, but I forgot was it was.)

  13. debacle

    flow Will do.

  14. flow

    yeah, I was assuming that some implementations have lost the information who published at the time the notifications are generated

  15. flow

    however, shouldn't it be possible to attach the publishing-entities full jid as metadata to the item, so that the notifcation generation entity could use it?

  16. debacle

    flow That might be possible. I'm not into server development and can't tell. In any case, it looks like 0060 needs a node publishing option "no-echo" or something like that.

  17. debacle

    0060 is far too short anyway.

  18. Holger

    flow: I didn't really look at things yet but would've assumed the notification is generated to the bare JID, no?

  19. Holger

    I.e. I don't think me problem would be to get at the publisher's full JID, but I wouldn't know how to omit it from delivery.

  20. flow

    Holger, interesting, didn't consider that. then we would need a message routing hint that says to not deliver the message to a particular resource…

  21. flow

    but yes, maybe just go with roster group

  22. debacle

    flow Fortunately, ejabberd does support that feature! (But e.g. prosody does not, too exotic?)

  23. MattJ

    I'm just curious if the "echo" is mandated by the XEP, or because the server thinks the publisher is subscribed and has a filter which accepts notifications from that node (+notify)

  24. flow

    MattJ, you are implicitly subscribed to your own presence, aren't you?

  25. flow

    Holger, what about an option that makes the pubsub service exclude yourself from presence based subscription models, that would work for debacle as far as I understand the situation

  26. Holger

    flow: Yes that would probably be simple to implement.

  27. MattJ

    flow: sure, but the +notify mechanism allows you to still not receive notifications

  28. flow

    uh, right we are in PEP-land here

  29. debacle

    Fun, fun, fun: It looks like the "echo" (headline messages) are not related to the subscription model (presence vs. whitelist), but to the fact, that we are now "interested" (in getting presence subscription requests from others).

  30. debacle

    Of course, we did both changes (PEP subscription model and own presence+interested) at the same time ;-)

  31. debacle

    Maybe we can be "interested" in subscription requests, but not PEP changes?

  32. Kev

    Don't advertise +notify?

  33. debacle

    Kev I believe, that we don't do that. At least, I don't see any "+notify" in the stream dump.

  34. debacle

    Is there a `-notify`? :-)

  35. debacle

    (Didn't see it in the XEPs.)

  36. Kev

    Maybe I misremember PEP, then, it's been a while. I thought you shouldn't get notifications unless you have +notify advertised.

  37. MattJ

    https://xmpp.org/extensions/xep-0060.html#filtered-notifications

  38. Kev

    Suggests I don't misremember, then?

  39. MattJ

    Indeed

  40. debacle

    Hm, so then why do we get notifications, if we didn't ask for them?

  41. Kev

    I'd suspect one of: * server bug * accidentally asking for them * I'm misremembering/reading spec.

  42. MattJ

    I think the spec has a little ambiguity in it, or a limitation. I don't see a way to enable filtered notifications, they seem to be simply used or not used for the entire pubsub service. That's okay because we generally use them for PEP and don't use them for generic pubsub.

  43. MattJ

    If this is PEP then I think it's likely a server bug

  44. Zash

    I believe ejabberd at some point had its own interpretation of filtered notifications, where everything is broadcast to everyone and the receiving server is meant to filter them. Dunno if that is still the case?

  45. Kev

    That bug was years and years ago though, I'm assuming that's long since fixed.

  46. Kev

    Assumption, mother of all, etc.

  47. Holger

    Yes that was changed over a decade ago, long before I ever touched ejabberd code myself, nevertheless I kept hearing complaints about that behavior surprisingly often 🙂

  48. Holger

    I think debacle might be running into this, but I can't look into things right now: > A service MAY auto-subscribe owners and publishers if they are not already subscribed https://xmpp.org/extensions/xep-0060.html#impl-autosubscribe (Why on earth MAY? Presumably because different implementations already did different things when the spec was written?)

  49. flow

    isn't that nice that its optional behavior?

  50. Holger

    How's that nice?

  51. Holger

    A client might prefer one or another behavior. In both cases it needs code to cope with both behaviors.

  52. Kev

    I think flow is using large doses of engineer sarcasm.

  53. Holger

    No jokes without explanation when I'm in the room!

  54. flow

    pff

  55. flow

    you are not in my office at the moment

  56. flow

    at least as far as I can tell

  57. flow looks under the table

  58. flow

    anyhow, it feels like we should add a layer of signalling and configurability over that MAY

  59. Kev

    It does feel that way.

  60. singpolyma

    > Hm, so then why do we get notifications, if we didn't ask for them? IIRC you enable filtering by having some +notify so without any you are unfiltered and may get everything? So maybe +notify for something random? Or dont listen to me it's probably one of the other things mentioned here

  61. singpolyma

    If you're being auto subscribed as the owner by the service then you can surely unsubscribe I think

  62. MattJ

    singpolyma [13:24]: > IIRC you enable filtering by having some +notify so without any you are unfiltered and may get everything? So maybe +notify for something random? Or dont listen to me it's probably one of the other things mentioned here I think that is one possible interpretation, yes. It doesn't actually say that though.

  63. MattJ

    I'm fairly sure Prosody doesn't behave like that

  64. MattJ

    It would, for example, mean that non-PEP clients would receive everything, which undermines the original goals of PEP

  65. Kev

    I'm 100% sure that wasn't the intent when writing PEP :)

  66. debacle

    I tried to explicitely unsubscribe from my own PEP nodes, but ejabberd insists, that I'm not subscribed.

  67. debacle

    OK, leaving the office for this week. Need to ride my bike to the station and take the night train to Brussels, which probably does not have Wifi :-)

  68. Guus

    l

  69. Guus

    Does anyone happen to have first-hand knowledge of the maturity of the MAM implementation in stanza.js?

  70. moparisthebest

    Uh I *think* singpolyma has been using that recently but apologies if I've misremembered

  71. singpolyma

    nope, I've been using xmpp.js

  72. moparisthebest

    Woah how long have I been thinking those were the same...