jdev - 2024-02-28


  1. lovetox

    https://xmpp.org/extensions/xep-0333.html > The Chat Marker message stanza MUST have a 'thread' child element if the message has been received, displayed or acknowledged in the context of a thread.

  2. lovetox

    why? it references a message id, its perfectly clear where this marker belongs to, a thread id should change nothing about it

  3. singpolyma

    Probably as an optimization if some hypothetical client did dispatch by thread before it looked at the message content? But yeah i dunno

  4. Stefan

    lovetox: re database model. I was playing with database trigger. Which will fill a table to have always a 'row data table' and a 'message view table' with 'current' messages. In will check later, if I can find it.

  5. james

    I see thanks singpolyma. do you have any public repo related to the sdk you are working on ?

  6. singpolyma

    james: https://github.com/snikket-im/snikket-sdk/ is where it will go eventually but mostly it's just on my workstation right now

  7. pulkomandy

    lovetox: Some IM clients (for example, mattermost) show thread messages both in a separate thread view and in the channel main view. So if you want to hrecisely know which previous messages are marked as read, you have to track if it's "all past messages" or "all past messages in that thread only"

  8. lovetox

    Ah I forgot that that we don't mark a single message

  9. lovetox

    Thanks

  10. lovetox

    singpolyma, i was successful with my approach, i join now all corrections from the same message table, further the join condition is so elegant that i dont have to do any validation on corrections. The join condition only joins corrections from the same account/remote_jid/direction(inc/out)/occupant id or resource (depending on whats there)

  11. jonas’

    letting SQL do the work :+1:

  12. singpolyma

    lovetox: nice!

  13. lovetox

    Markers XEP, i wonder how to store this in the DB, until now i had the idea, i save every marker i receive message id -> marker or something

  14. lovetox

    but now im thinking how to display this in the UI, and in the UI i think i would only ever show the last marker received, so it makes less sense to store historically all markers

  15. lovetox

    something like occupant id | last stanza id | marker (displayed/received)

  16. lovetox

    specifically in mucs with a lot of occupants, i think storing every marker is not feasible, this would fast amount to a huge amount of data which the user probably doesnt need