jdev - 2024-02-07


  1. edhelas

    Working on a new XEP, Pubsub Items Acknowledgement

  2. edhelas

    https://github.com/edhelas/xeps/blob/master/inbox/pubsub-items-acknowledgment.xml

  3. edhelas

    Tell me if you see weird stuff or bad wording in it before I propose it :)

  4. singpolyma

    edhelas: doesn't the pubsub service already know who it has delivered items to? So why does it need a special acknowledgement?

  5. edhelas

    It's not about delivery, but "read status"

  6. edhelas

    It's basically to sync Pubsub clients together

  7. edhelas

    I need this XEP to write the Stories one

  8. edhelas

    This also allows publishers to know if their item was read their subscribers

  9. pep.

    Can you also make another re pubsub read state sync for one's own clients that doesn't spread info to other entities? :P

  10. edhelas

    pep. It's opt-in

  11. edhelas

    If you don't want to "spread info", you just don't send the info

  12. edhelas

    In Movim I'm planning to put a toggle for that

  13. pep.

    Not what I'm asking but that's ok

  14. pep.

    I'm not saying you don't need such a spec, I'm saying there's some use-cases that are also useful that it doesn't cover

    πŸ’― 1
  15. edhelas

    "Disable the Stories read acnkowledgement - This will disable read status between your different devices [X]"

  16. pep.

    While these two things don't need to be grouped together

  17. pep.

    Is what I'm saying

  18. moparisthebest

    > I'm not saying you don't need such a spec, I'm saying there's some use-cases that are also useful that it doesn't cover πŸ’―

  19. moparisthebest

    If it was your own node, you could use it for syncing all the stuff you want to sync, including this, and avoid spamming all this private data all over the place all at once (including read markers in 1:1 and MUCs)

  20. singpolyma

    Yes, I don't see any reason why "read state" is going to the pubsub service. This seems like something to store in your own pep node, just as we've discussed doing for read state in open chats etc

  21. singpolyma

    if it's to sync *my clients* why is it going to anything by my server?

  22. pep.

    Well here the goal isn't to limit to to one's own devices

  23. pep.

    But maybe there's a way to combine both, dunno..

  24. pep.

    it's quite annoying when this use-case is never taken into account. Chatstates, chat makers, receipts.. yay privacy :)

  25. singpolyma

    If it's about read status I'm also not sure why it's part of the retrieval query -- I have to retrieve (or, more likely, have an event pushed to me) *before* I can read it, no?

  26. edhelas

    > if it's to sync *my clients* why is it going to anything by my server? One of the goal is also for the publisher to know who has read its content

  27. edhelas

    You can't build social networks on XMPP if you at least don't do a bit of social interaction between users

  28. edhelas

    And again _its opt-in_

  29. singpolyma

    Sure, but I've never seen a social network that shows me who has read my posts. I mean, I'm not saying that's not useful, but it's hardly a fundamental feature

  30. edhelas

    > it's quite annoying when this use-case is never taken into account. Chatstates, chat makers, receipts.. yay privacy :) Be my guest to write the XEP to do so

  31. moparisthebest

    I think we need a way to sync private data for sure another seperate mechanism to tell others you've read things could be useful too But these shouldn't be the same thing (because everyone wants 1, you may want to disable 2)

  32. singpolyma

    It's not about being opt-in or not. You keep saying you need this in order to do stories and I'm not sure why

  33. edhelas

    https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/WE8sbhakc61T/image.png

  34. edhelas

    Instagram

  35. edhelas

    https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/RKCKitiissi2/image.png

  36. edhelas

    Twitter

  37. edhelas

    And I can post other examples as well

  38. pep.

    moparisthebest, do they need to be separate? You're still sharing the same information. Just to different entities

  39. edhelas

    > It's not about being opt-in or not. You keep saying you need this in order to do stories and I'm not sure why Because Stories have a read state, if not if two clients implements stories, I'll continuously have to "clear" their states

  40. singpolyma

    edhelas: but that's about the client's read state

  41. singpolyma

    not about pubisher being able to see who has read it

  42. edhelas

    No, the JID read state regarding that story

  43. moparisthebest

    pep.: perhaps not, I was just saying that the only mechanism shouldn't be #2 which you try to use for #1 (which is what we have now)

  44. pep.

    moparisthebest, yeah I agree

  45. edhelas

    And yes it can by sync on the story node OR the JID itself, I choose the first one to also get that "publisher statistics" use case

  46. edhelas

    If you want the second option, again, be my guest to write the other XEP

  47. moparisthebest

    > And yes it can by sync on the story node OR the JID itself, I choose the first one to also get that "publisher statistics" use case They need to be separate for privacy reasons though

  48. pep.

    edhelas, fwiw, I already have to clear my read state on every single device because I don't activate any of (chatstates, markers, receipts) because these all share info with entities other than my own devices. So I do get it's annoying :P

  49. moparisthebest

    There is no reason at all for them not to be separate, is there? I might be missing something

  50. singpolyma

    And also just for usefulness reasons. Like, it's not just a privacy problem it's also going to be a pain to fetch my read states from umpteen remote servers

  51. moparisthebest

    That too

  52. pep.

    True

  53. singpolyma

    pep.: well, that's different, that's because we don't have read state sync of any kind yet. That's coming

  54. pep.

    (Once I get what umpteen mean)

  55. moparisthebest

    > (Once I get what umpteen mean) pep.: Just means "many" or "a lot"

  56. pep.

    Ok

  57. moparisthebest

    Now that you mention it I have no idea where that word came from or where I learned it lol

  58. pep.

    I thought something like "offline"

  59. moparisthebest

    Language is the worst

  60. edhelas

    > And also just for usefulness reasons. Like, it's not just a privacy problem it's also going to be a pain to fetch my read states from umpteen remote servers Reconciliating your private PEP "read status" node and your subscriptions is also "a pain"

  61. edhelas

    What if I have a read status for a nod ethat doesn't exists

  62. edhelas

    Also

  63. pep.

    Just discard it then?

  64. edhelas

    And welcome to stanza spam

  65. pep.

    stanza spam?

  66. pep.

    You mean stuff that your own client added to a node you're the only one to have access to?

  67. singpolyma

    > Now that you mention it I have no idea where that word came from or where I learned it lol according to wiktionary it literally means β€”teen as in a number with an unspecified first part I guess? language is fun

  68. edhelas

    > I receive a pubsub notification header > I send a payload request to get the content > I receive the payload content > I read it > I send my server the fact that I read the content > My other client have the notification header > My other client get the notification that I read it on my first device

  69. edhelas

    Multiply that by the amount of item delivered * the clients

  70. edhelas

    <3

  71. edhelas

    My proposal actually doesn't add any new stanza

  72. edhelas

    It's just metadata in the current 0060 flow

  73. edhelas

    Also because it happen during those flow, you can greatly optimize the DB queries

  74. edhelas

    I would prefer not to end up with Matrix like performances, that's also why I've asked some server guys to validate the flow as it can be touchy regarding the scalability issues

  75. pep.

    edhelas, clearly here goffi and you are the two clients mostly using PubSub stuff. If you're not planning to support some kind of privacy feature for this, I won't bother doing it. Also why I'm somewhat trying to see if there's a way to make it fit into this spec

  76. pep.

    (Well you're not clients, you're client developers, sorry :p)

  77. edhelas

    To me it's a balance between offering features and privacy yes

  78. pep.

    Well you're not offering privacy here, you're offering feature without privacy, or no feature

  79. moparisthebest

    >> I receive a pubsub notification header >> I send a payload request to get the content >> I receive the payload content >> I read it >> I send my server the fact that I read the content >> My other client have the notification header >> My other client get the notification that I read it on my first device Which one of these is the read state in ? And is it only my read state or everyone who's read it?

  80. edhelas

    moparisthebest this is only you and your read state

  81. edhelas

    The full list might only be accessible to the item publisher

  82. edhelas

    Obviously, if not it would then be a serious security flaw

  83. moparisthebest

    If we want to minimize traffic and don't care about privacy we should all just use Facebook messenger, it's a sliding scale with that being the far end

  84. moparisthebest

    edhelas: I'm asking does it come in the notification or after you've fetched the contents? In your design

  85. edhelas

    > If we want to minimize traffic and don't care about privacy we should all just use Facebook messenger, it's a sliding scale with that being the far end Thanks for constructive comment <3

  86. edhelas

    > edhelas: I'm asking does it come in the notification or after you've fetched the contents? In your design In my XEP, that I posted just before, you can actually read that the <acknowledged/> state is in both

  87. pep.

    I assume the flow actually doesn't change much when you use edhelas' current proposal, because all your other online devices already got the push from the remote pubsub server.

  88. pep.

    It saves a roundtrip for offline devices

  89. moparisthebest

    1 roundtrip to your own server total, I think

  90. moparisthebest

    The other clients don't bother fetching because they see it's read, I guess

  91. pep.

    Well they would get it anyway if your account is subscribed

  92. pep.

    And yeah they would probably still fetch it I think even if it's already read

  93. pep.

    just to display it greyed out or sth

  94. moparisthebest

    So if the stanza to/from your own server is less than <acknowledged/> twice it's actually less traffic...

  95. moparisthebest

    Does anyone have stats on s2s bidi ? Or, is it the default in any ejabberd/prosody release, anyone know?

  96. Zash

    Not enabled by default in Prosody. Don't think ejabberd implements it at all.

  97. moparisthebest

    Do you think it might be the default in a near future version of prosody?

  98. moparisthebest

    Maybe I'm just asking how stable you think it is :)

  99. Zash

    Not sure if that's the same question.

  100. Zash

    It's Stable. I can't remember any problems with it since we figured out a way to pass stream features in both directions for stanza size limits.

  101. Zash

    And that was more of a spec problem than an implementation problem.

  102. Zash

    12% of connections to/from conference.prosody.im are bidi

  103. moparisthebest

    bidi would enable cool things like, say you have a bot that only joins MUCs, it could just do s2s itself, no server, no c2s, no ports open 😈

  104. moparisthebest

    12% seems super high for something that isn't the default, that's promising imho

  105. Zash

    I think if we're to enable it by default, we need to have ways to detect and correct that case when it's unintentional.

  106. Zash

    Since it can hide one-directional connectivity problems.

  107. Zash

    I do find it fun to have working s2s from my laptop development server when on the go

  108. moparisthebest

    > Since it can hide one-directional connectivity problems. Yes that's really the only problem, but it's kind of a hard one, because it's not *really* a problem πŸ€”

  109. moparisthebest

    What if we introduced a optional feature that says "don't try to connect back to me, I know what I'm doing" and for anything that doesn't send that, servers can schedule a connectivity check for it, and if it fails, send a message to the server admin (over the working bidi of course) ?

  110. moparisthebest

    I say "schedule" because it shouldn't block anything and can just be done at the server's earliest convenience, like maybe it'd only do 1 at a time when server load is low or whatever