Modern XMPP project discussion - 2019-10-21

  1. lovetox whats your opinion on "read state", how should apps display this in a groupchat
  2. lovetox today i looked at whatsapp, they show on every message exactly what users "read" that message
  3. lovetox But im not sure about their protocol, i think they send a read message for every message maybe?
  4. lovetox the way we do it now, we send a read marker for a message-id, and then the client should assum from that everything before was also read
  5. lovetox but this is quite hard. Say i have a chat that goes back a year, a user joins and sends a read marker for the last message in the muc
  6. lovetox does this mean he has read the last year of history?
  7. lovetox should i show now on every message "User X has read this"
  8. Ge0rG that's the difference between 0184 and 0333
  9. Zash Isn't 333 also per individual message?
  10. lovetox no
  11. Ge0rG we should have a third one, per-thread.
  12. MattJ It's two different models of unread tracking
  13. Zash related and iirc sane
  14. MattJ I think yaxim is quite unusual in that it actually does track per message
  15. MattJ Yeah, Facebook only tracks the latest (un)read with a pointer
  16. MattJ which is the 333 style
  17. Ge0rG MattJ: it's more weird than that. It will locally mark as read per message based on what you've seen, but it will assume the full history as read if you send from another device
  18. MattJ Both have their advantages
  19. MattJ Slack's unread handling is so very annoying
  20. MattJ Also around here is the land of the "What does 'read' mean?" debate
  21. lovetox i dont see anything relevant in that article
  22. lovetox thats about how to keep storage and APP (whatever that is) in sync
  23. lovetox im talking about how read markers should be displayed to the user
  24. lovetox easiest way is probably the "X read up until here"
  25. lovetox thats exactly what you can do with 0333
  26. Ge0rG Riot/Web will display a set of avatar bubbles on the right side
  27. Zash Doesn't Conversations do that kind of thing too?
  28. lovetox yes, im asking myself if i can do more than that
  29. pep. Zash: yeah similar in groupchats iirc
  30. lovetox but everything else seems quite hard with that kind of protocol
  31. lovetox also its conceptually very different to receipts
  32. lovetox where i can indeed track every message and who received it
  33. lovetox so those two need a different storage model
  34. Ge0rG I wish we had built multi-receipts into 0184
  35. lovetox on receipts ijust log message-id / jid
  36. lovetox on read markers, i log last-message-id / jid
  37. Ge0rG there is an issue with markers when your recipient lost a subset of what you sent, i.e. due to s2s issues
  38. Zash receipt on addition to MAM!
  39. Ge0rG Zash: I've been thinking about that, but no, please not.
  40. lovetox but maybe i do this..
  41. lovetox then showing only diplay marker on the messages where at least on person is currently
  42. lovetox maybe whatsapp went overboard with that
  43. lovetox really it only means "displayed"
  44. Link Mauve lovetox, note also the social issues with read messages.
  45. lovetox the device displayed it, nothing can be said about "read"
  46. Link Mauve Which is the main reason why I would never want it to be implemented anywhere.
  47. lovetox so maybe we should not go too much into detail like showing it on every message
  48. lovetox as if we had proove they read that
  49. Link Mauve It creates the expectation that the recipient will answer your message once they have read it.
  50. Link Mauve While there are many cases where this won’t happen.
  51. lovetox yes Link Mauve i agree
  52. Zash Link Mauve, +1
  53. lovetox i would default to OFF for that setting anyway
  54. Ge0rG show a confirmation dialog after each message. win-win!
  55. Zash "have you read this yet? [yes] [not yet, get out of the way so I can read!]"
  56. Zash every 3 seconds until every message is read
  57. Ge0rG [YES] ...more options...
  58. Zash 'have you read "have you read this yet" yet'
  59. Roobre I do not think we (as a society) should cripple technology just because people have toxic relathionships
  60. Zash Mastodon crowd would like to have a word with you
  61. Link Mauve Roobre, I don’t think we (as makers) should create technology that thrives on people’s toxic relationships.
  62. Zash Link Mauve, but how will we get people addicted so we can get funding????
  63. Link Mauve Damn, my plan is once again foiled by capitalism!
  64. Roobre For me, read recipts are a very useful tool to see if my message was actually delivered
  65. Roobre But I agree with it being opt-in to both parties
  66. Zash Delivered ≠ read.
  67. Link Mauve Delivery receipts are enough for that, assuming no bug on the recipient’s software (but that’s also an assumption you have to make with read receipts).
  68. Zash Mmmm, ask two generals about that
  69. Daniel > Roobre, I don’t think we (as makers) should create technology that thrives on people’s toxic relationships. Not sure if that's what you meant. But I don't think that read markers thrive on toxic relationships
  70. Daniel You could make an argument that they might enable such behavior
  71. Daniel But they are quite useful outside toxic behavior
  72. Roobre Zash Ok, call them "Shown" receipts instead (?)
  73. Roobre Delivery means nothing nowadays, with most people having their phone in silence
  74. Roobre I agree with Daniel
  75. Zash Not lost, will be read eventually.
  76. Zash Async communication.
  77. Daniel It already didn't mean anything when people had jabber running in a screen session on a server they forgot about
  78. Zash Nothing means anything.
  79. Ge0rG Luckily, most of those forgotten clients didn't support delivery receipts... 😜
  80. lovetox i think in groupchats its just really spammy
  81. lovetox receipts and display markers
  82. Ge0rG lovetox: in channels they are, in group chats, they probably have value for the users
  83. Daniel For me they seem to work fine for relatively large private group chats
  84. lovetox i guess we should not worry about that, at last mobile and internet become faster and faster
  85. Zash serverside disco#info-based filtering would probably help there
  86. Zash at least with the feeling that we're wasting bandwidth :)
  87. Ge0rG Zash: it would help with so many aspects, that it hurts to see it's not implemented yet
  88. pep. Indeed