XSF Discussion - 2023-11-07


  1. edhelas

    Was there already some discussions and though about having a way to add a "trust" system on JID based on the network ?

  2. edhelas

    Like other JIDs can "proove" that a JID is legit or something like that.

  3. edhelas

    Like other JIDs can "prove" that a JID is legit or something like that.

  4. Daniel

    edhelas: I reckon you are talking about something like verification in mastodon rather than e2ee

  5. Daniel

    For e2ee there ist ATM

  6. MSavoritias fae.ve

    yeah if its for thrid parties to verify a jid is legit idk of anything being worked on. if its for a person to verify that the person sending the contact request is not a spammer i plan to start writing a xep for it one of these days.

  7. edhelas

    > edhelas: I reckon you are talking about something like verification in mastodon rather than e2ee Yes inseed

  8. edhelas

    > edhelas: I reckon you are talking about something like verification in mastodon rather than e2ee Yes indeed

  9. MSavoritias fae.ve

    well the mastodon thing can just be added to the vcard of an xmpp profile no? from reading its just a link you add to your site. (unless we are looking for another solution.)

  10. MattJ

    Keyoxide, too

  11. MSavoritias fae.ve

    right thats another good solution

  12. edhelas

    https://snyk.io/fr/blog/verify-and-secure-your-mastodon-account/

  13. edhelas

    Indeed, that's a very simple way to do it :)

  14. edhelas

    And can be easily done within vcard

  15. edhelas

    A small XEP to re-explain the flow in a XMPP client could help maybe 🤔

  16. Kev

    Is anyone aware of XMPP clients that do either 'mark unread' or 'remind me about this message in X long'?

  17. emus

    > Kev: > 2023-11-07 11:31 (GMT+01:00) > Is anyone aware of XMPP clients that do either 'mark unread' or 'remind me about this message in X long'? thatwould be great

  18. pep.

    Probably weird in an IM setting? Maybe something à la Slack yeah?

  19. pep.

    I don't know of any

  20. cal0pteryx

    > Probably weird in an IM setting? Maybe something à la Slack yeah? Not at all weird in an IM setting. I often wish for a "reminder" to answer people later

  21. MSavoritias fae.ve

    me too. reminders would be nice

  22. pep.

    Wasn't it possible in poezio to put the "unread bar" at some specific place? I don't really use this bar unfortunately

  23. edhelas

    > Not at all weird in an IM setting. I often wish for a "reminder" to answer people later A "bot" like feature would do it no ? /remind me 2 days

  24. edhelas

    > Not at all weird in an IM setting. I often wish for a "reminder" to answer people later A "bot" like feature would do it no ? /remind-me 2 days

  25. pep.

    I guess the interface depends on the clients. Implement it however you want :)

  26. Kev

    Any interest in standardising a PIP node for reminders? Presumably it's just ``` <reminders> <reminder at='timestamp' jid='contact' mam-type='[local|remote]' id='mam-id'/> <reminder.../> </> ``` or thereabouts.

  27. pep.

    Could this have anything to do with synchronizing read state?

  28. Kev

    I think they're unrelated.

  29. Kev

    Or, at least, logically distinct.

  30. pep.

    The 'mark unread' I do think they are. For the reminded, yeah ok

  31. pep.

    The 'mark unread' I do think they are. For the reminder, yeah ok

  32. Kev

    Protocol-wise, I think 'mark unread' is just another application of synchronised read state. You're just setting the read state in PIP to an older id instead of a newer one.

  33. pep.

    PIP? PEP?

  34. Kev

    PIP=Private PEP :)

  35. pep.

    Ah ok

  36. Kev

    For whimsical reasons, we had PEP, PIP and POP.

  37. pep.

    POP? Open PEP?

  38. Kev

    https://xmpp.org/extensions/xep-0223.html was PIP

  39. Kev

    https://xmpp.org/extensions/xep-0222.html was POP. IIRC.

  40. pep.

    "You're just setting the read state in PIP to an older id instead of a newer one." hmm not if you're just unreading a single message

  41. Kev

    I don't see the value in treating read state as non-contiguous. I'm sure other people do, but it fails the complexity/value test for me.

  42. pep.

    Just like I set emails as unread in my inbox. I see value in it

  43. pep.

    I don't set all emails as unread until a past date

  44. Kev

    I should say 'read state [of a thread]'

  45. pep.

    That doesn't translate well in XMPP terms yet, but yes that makes more sense

  46. Kev

    Although really, I don't have the need to set unread state in clients that support reminders.

  47. Kev

    For how I use chat.

  48. pep.

    Maybe, but they're distinct features still, I think

  49. Kev

    Slack I use reminders, because it supports them, Discord I use Unread as a poor substitute, because that's what it supports.

  50. pep.

    You can also have reminders without setting a message as unread

  51. Kev

    Yes. For me, I don't need to mark as unread at all, if I have reminders.

  52. Kev

    I do accept that my way of using IM isn't the only valid way :)

  53. pep.

    I don't have much stakes in the reminder field, happy for it to be a thing, or not :)

  54. Andrzej

    I would prefer to have reminders than keeping single messages as "unread", as with reminders I can mark "to do" items in chat. I wonder if having a possibility to just mark single messages wouldn't be enough, but then, most likely I would like to have a multiple lists with those marked messages....

  55. lovetox

    unread is insufficient

  56. lovetox

    because the client does not know when you want to mark them read

  57. lovetox

    what if you switch to the conversation, your unread marked message would become again read

  58. Kev

    As I say, I think (for me), reminders obviates the need for marking things as unread, at least most of the time.

  59. lovetox

    usually clients mark something read, as soon as its displayed on the screen, which is not what you want with reminders

  60. lovetox

    yes Kev, i support your point, read state is a poor man reminder

  61. lovetox

    and insufficient for the task

  62. lovetox

    i really like the idea, its also pretty easy to implement, a pubsub node, and a bit of UI magic

  63. Kev

    I think the sensible UI is the harder part than the protocol :)

  64. lovetox

    i would go with Andrzej idea, as soon as you have set a reminder, there is some UI element that displays the list and messages of all your reminders, like a ToDo list in issue trackers, of course if you click on it you can jump to the conversation to get maybe context

  65. MSavoritias fae.ve

    that sounds like a nice idea

  66. Kev

    Well, and presumably showing some sort of notification and unread-ish marker when the reminder time arrives.

  67. lovetox

    thats the question if needed, i would show a button with the count of reminders at all time

  68. lovetox

    so everytime you look at the application, you know, there is still something todo

  69. lovetox

    not sure if i would implement that "remind me in X hours thing"

  70. pep.

    "read state is a poor man reminder". Maybe we can accept read state is just a different use-case?

  71. Andrzej

    I think "remind in" could be an option

  72. jonas’

    reminder sucks

  73. jonas’

    (for my workflow, it may work for yours)

  74. jonas’

    things reminders do which unread does not: - need me to think about when I'll have time for this - pull me out of focus when they trigger at a bad time because I misjudged the first thing

  75. pep.

    ^

  76. jonas’

    so those are orthogonal use-cases

  77. jonas’ out

  78. lovetox

    These UX discussions are better made by users with the developers, it does not hurt to add the option to set a time to the pubsub item

  79. lovetox

    personally i would also not do the alarm thingy from the start

  80. lovetox

    more treat it like a todo list

  81. Andrzej

    "remind me in X" doesn't need to result in alarm, it could, but it could just mark some items as "overdue/need action" and just display badge in the client UI

  82. Kev

    Presumably it can use a similar badge to 'unread', if the unread badge is not distracting to you.

  83. MattJ

    Yeah, I use Gmail's "snooze" feature quite a bit, which may be related

  84. Zash

    Are you inventing email?

  85. Kev

    Same effect, I think, yes Matthew.

  86. MattJ

    That's more because I deal with a lot of email and stuff can get buried, but "snooze" will bump something to the top of my inbox at a time I'll be able to deal with it

  87. MattJ

    I can't actually imagine doing that in IM, because I don't have enough new chats opening daily in that context for stuff to get truly buried, a "mark unread" would suffice

  88. MattJ

    And I suspect that's the difference between the two

  89. Kev

    I somewhat frequently get messages in IM that I have to deal with, but can't deal with yet, and use reminder for that.

  90. Kev

    By far the most common is when a message comes in towards the end of the work day that I want to deal with in the morning, followed by a personal message coming in during the work day that I want to deal with out of hours.

  91. MattJ

    Similar for me, if work stuff comes in out of hours and I'm on my phone and need to reply from my laptop, I'll snooze it until a time I'll be at my laptop

  92. moparisthebest

    Instead of "actively remind me" it could be "bookmark this, put it on a to-do list I'll handle later, optionally remind me"

  93. moparisthebest

    The protocol is probably the same, the UI is a bit different

  94. MattJ

    "Reminder" can be associated with alarms/notifications/etc. but I think in this case it's more like a nudge that is usually wanted - a silent notification at most

  95. Kev

    For me, I'd like my client to treat them as it would a new direct message, I think, with the same notifications that would have. But I can see merit in having them without a time associated so they're in the list immediately.

  96. marc0s

    > Is anyone aware of XMPP clients that do either 'mark unread' or 'remind me about this message in X long'? shameless plug... I did write this https://xmpp.org/extensions/xep-0435.html back then... Never got past a prosody module https://hg.prosody.im/prosody-modules/file/tip/mod_reminders, with no client implementation that I know of. It was thought as reminders à la slack, as told before. Main usecase was the one MattJ said: you catch a message in your cellphone while out of job already and don't want to miss it tomorrow morning.

  97. lovetox

    yes great, but i see no reason why this should be depending on some reminder module on a server, store the information in pubsub. Further clients can read a clock themself, no need for a server to send a message

  98. Kev

    It does seem like PIP is perfectly adequate (and preferable) for this.

  99. Fishbowler

    I'd definitely use bookmarks

  100. Zash

    Bookmark extension for ... unread?

  101. nicoco

    That wouldn’t work for 1:1 chats though?

  102. Zash

    Don't we already have 333 for that, which works in MUC, even public ones .. awkwardly.

  103. pep.

    333 Doesn't allow syncing read state without leaking that to everyone else

  104. Zash

    The Tigase folks apparently do it with MUC PMs to oneself.

  105. pep.

    Maybe we still don't need to go through MUC for that

  106. Fishbowler

    I don't think I want unread. I'd want an ability to pick a message that's bookmarked for later reference.

  107. nicoco

    I haven’t read the whole discussion, but I saw talks of ‘remind me later’/‘mark as unread’ passing by today which 333 does not cover at all. I don’t have ideas as to how it should be done, but I sure think it would be a feature I’d use. Usually I just leave messages as unread from my phone when I plan on replying later (usually when I’m on a real keyboard), but it’s not excellent.

  108. Fishbowler

    Unread is disingenuous. I did read it. It's a method from email to use unread as a proxy for to-do or similar. That doesn't feel like it'd work well for streams of messages to mark 1 of them as unread.

  109. Zash

    If it's just a note/reference to yourself then sure, some private PEP thing makes sense.

  110. nicoco

    > Maybe we still don't need to go through MUC for that The tigase folks approach has the drawback of requiring the MUC to allow PMs and some don’t (and yes, gateways are examples of that, AFAIK semianon groups with group-mediated PM is more or less an XMPP-exclusive feature ^^)

  111. jonas’

    Fishbowler: it works very well for me in rocket.chat

  112. jonas’

    your argument is invalidated by practical experience

  113. Zash

    nicoco, yeah had to fix the anti-PM module when it was deployed here :)

  114. nicoco

    Jonas’ and does the other party see that you’ve read the message or not? Also, why aren’t you the author of slidge-rocketchat already? 😉

  115. pep.

    I do agree the terminology doesn't make much sense when it comes to "unread", but usage is ok

  116. Zash

    Invent a way to bookmark stanzas, use that later for topic / pinned messages in MIX :)

  117. jonas’

    nicoco: (a) they don't see either because that is not a thing, (b) I'm not going to invest private time for workstuff

  118. Zash

    I gather from Slack that you're supposed to use reactions for "I read this and had nothing useful to say so I reacted with 🦆️ or something"

  119. nicoco

    (a) Oh I see, same as mattermost then (b) work? yuck! Didn’t AI free us of this yet?

  120. Zash

    nicoco, no AI freed us from the fun stuff like making art and music

  121. Zash

    https://xkcd.com/2565/ where one end is an AI thing, this is the future :)

  122. nicoco

    You’re kidding about reactions but acking messages is actually a great use case for reactions IMHO. Not a single messager I know is 100% reliable when it comes to read markers, because it has to rely on focus, which sometimes does not mean you’re actually behind the device where the chat is focused.

  123. jonas’

    nicoco: well did you think I'd use anything but XMPP for non-work stuff? :P

  124. jonas’

    nicoco: yep, reactions are great for that

  125. nicoco

    Of course, AI/webcam could be a thing for actually reliable read marks but HELL NO.

  126. jonas’

    I doubt that

  127. jonas’

    sometimes I read messages and immediately drop them out of my memory. are those "read"? :)

  128. nicoco

    AI/brain-connected device it is then.

  129. jonas’

    (but this is going off-topic)

  130. jonas’

    see and so we need mark unread again

  131. jonas’

    for when I forget and the brain interface notices

  132. Zash

    Btw 333 specs a way to acknowledge message, wasn't there agreement to drop that part?

  133. nicoco

    I don’t know but I haven’t seen a single implementation of this marker, is there any out there?

  134. Zash

    and the part that overlaps with 184 and 198

  135. nicoco

    > If the sender determines that the recipient's client does not support the Chat Markers protocol then it SHOULD NOT send Chat Markers or markable messages. I think that this part is not great either, because (a) the contact might have other devices that might support them, and (b) until we have a better XEP for read status, I actually want my markers sent anyway, so my other devices know that I’ve read the message(s). Maybe there is a justification for this that I am missing?

  136. Tobi

    Am I reading our repo correctly that it doesn't require yearly updates to software entries to keep them on the website?

  137. Tobi

    Am I reading our repo correctly that it doesn't require yearly updates to software entries anymore, to keep them on the website?

  138. pep.

    iirc the main point of updating every year was to drop unmaintained software. Nowadays unmaintained software just don't have a doap file :x

  139. Zash

    Tobi, that was the idea, yes

  140. Tobi

    So relying on the hosted-doap folder would be a bad idea?

  141. Guus

    Yeah, the yearly update got replaced by DOAP

  142. Zash

    The idea being that you need to keep up with the compliance suite, not keep some timestamp within one year

  143. Tobi

    Ahh. I see. Ta.

  144. Zash

    DOAP can carry latest release info, dunno if anyone does that. Could also be something to factor into something, but on the other hand that doesn't really mean much.

  145. pep.

    poezio / slix do that yeah