XSF Discussion - 2018-06-30

  1. labdsf

    See https://delta.chat for IM over email

  2. j.r


  3. j.r

    Is there a way to delete messages in mam?

  4. daniel

    j.r: no standardized way

  5. j.r

    that's bad

  6. j.r

    What means not standardized?

  7. daniel

    That there is no standard way of doing it. Some servers or providers might have their own protocol

  8. j.r

    Oh ok

  9. pep.

    labdsf: "Independent: You are not dependent on any external service or server - Delta Chat only uses your mail server." Can I laugh

  10. labdsf

    pep.: dunno what you laugh at, it basically means they don't run any infrastructure

  11. pep.

    Well yeah they use email. I guess they only provide the client, the server being gmail for most people, I don't see how that's not being dependent

  12. jonasw

    (also, it is really sucky when you don’t have DeltaChat)

  13. jonasw

    (a friend of mine tested it briefly)

  14. MattJ

    jonasw: in what way? (I could guess, but just curious)

  15. Link Mauve

    “23:15:59 SamWhited> Client UIs are primarily designed for short form messages that are meant to be read right away.”, there are quite a few clients which have a better UI for that, try Movim or Libervia.

  16. SamWhited

    "primarily" was the keyword there.

  17. Link Mauve

    It depends on the client.

  18. Link Mauve

    IM clients do IM primarily, other clients do other things primarily.

  19. SamWhited

    And XMPP clients are primarily IM clients.

  20. Link Mauve

    Is there any use to this information?

  21. SamWhited

    I'm not sure what you mean; I was just asked a question so I answered it.

  22. Ge0rG

    I wouldn't be surpried if non-IM XMPP clients vastly outnumbered IM XMPP clients, but we just can't see them.

  23. ralphm


  24. SamWhited

    Probably not in such a way that moving the newsletter to them would be helpful though; I doubt a million and one IoT devices or whatever want to read the newsletter.

  25. daniel

    Once they become self aware they might

  26. Ge0rG

    BBL, taking my laser printer into installing conversations.

  27. flow

    Ge0rG, whut?

  28. flow wonders if a "in final recipients MAM archive delivery receipt" would be desireable. Any thoughts?

  29. Ge0rG

    flow: 0184 kind of breaks with multi device cases, but still I'd consider it a bad idea to ack on MAM storage. Instead, we should fix xmpp to reflect an error if the message didn't reach the recipient's MAM

  30. Ge0rG

    You could add another level of ack of course, which is less than "delivered to user's device", but I don't see any value in it for IM

  31. flow

    Ge0rG, why do you think that it is a bad idea?

  32. Ge0rG

    flow: abusing 0184? because "stored in MAM" is less of a delivery guarantee than "received by user's device"

  33. Ge0rG

    flow: think of "the user lost their device last week, and won't ever login again, but MAM is still running"

  34. waqas

    I agree with Ge0rG that using 0184 is a bad hack, as it's intended for end-to-end receipts. 0198 gives you single hop receipts already.

  35. Zash

    Does 184 say something about how to make sense of it in a multi-device environment?

  36. waqas

    No, it's more like "some device received it"

  37. Ge0rG

    I think that in combo with MAM, it's a good approximation of "at least one device received it, and the others are going to eventually sync up"

  38. Andrew Nenakhov

    Storing delivery receipts in mam for each message would no no good.

  39. Andrew Nenakhov

    Hacks to store "empty" messages to act as read receipts are no good either.

  40. Ge0rG

    Andrew Nenakhov: what's the problem with storing receipts in MAM?