jdev - 2021-03-18

  1. jubalh

    I didn't know about EME

  2. jubalh

    Seems like a nice thing to know in advance which encryption type is used. I remember that we have quite some ugly code there, not setting this right when we get the stanza in all cases. But only discovering it later because _ (forgot the reason). Probalby was only discoverable later on.

  3. jubalh

    Would love to rewrite this to just check right at the beginning. But I guess I can't rely on clients using EME?

  4. jubalh

    lovetox: are you sure that many implement it?

  5. defanor

    Since EME is not required by the core protocol, it indeed sounds like a bad idea to rely on it (especially when not necessary), even if many do implement it.

  6. Zash

    You should probably look for the encryption methods you support first, then if you find nothing you understand, then you can check for EME and tell the user that the message is encrypted with some unknown method.

  7. Zash

    Show the <body>, if any, too. But an EME thing lets you apply i18n and such.

  8. jubalh

    Yep, I'm planning to rewrite it like that :)

  9. Link Mauve

    defanor, each encryption method should recommend to include it.

  10. defanor

    Link Mauve, that'd be a sensible recommendation, yet reliance on it still sounds bad, if it's for anything important. For instance, if a client would only decrypt messages if they contain an EME element: that'd lead to message loss when it shouldn't happen. Though maybe that's not what was meant above.

  11. Link Mauve

    defanor, that’s not what EME is for.

  12. Link Mauve

    It’s only there for the case where you don’t have any other hint that the message is encrypted.

  13. defanor

    Perhaps I've misinterpreted the intention then.

  14. Link Mauve

    So that for instance when clients will start migrating to omemo:1, clients from today would notify the user that they can’t decrypt these messages they receive.

  15. Link Mauve

    Or if you get OTR messages carbon’d and your client removed support for that.

  16. Link Mauve

    Basically, for backwards and forward compatibility.

  17. Link Mauve

    If you can decrypt a message, you know about the mechanism and don’t need EME.

  18. jubalh

    it still would be nice to know right from the start how to try to decrypt it

  19. Sam

    Hi all, if you're interested in attending any of the office hours / hangouts, please remember to fill out the availability survey (no need to put your name if you don't want to)! https://whenisgood.net/kr97tfy

  20. mathieui

    jubalh, except with OTR, you usually do as you have a specific elemetn for that

  21. Ge0rG

    Sam: For a brief moment, I thought this was another case of automated MUC spam... :D

  22. Sam

    oops, sorry

  23. Ge0rG

    Maybe I just get triggered too easily

  24. Sam

    I don't think MUC spam is something I've seen much of, but I'm that way with emails and stuff all the time. Any time I get something that has a wiff of that spammy writing I have that gut instinct to mark it as spam before I realize it's somebody I asked to email me or something.

  25. Ge0rG

    Heh.

  26. Ge0rG

    Sam: there were maybe two or three MUC spam incidents so far this year

  27. Sam

    Speaking of spam, I should prepare an email reminding everyone to go to Daniel's talk tomorrow :)

  28. Ge0rG

    Sam: half of the office hours time slots have passed already. Does it make sense to also populate the first days in anticipation of a weekly recurring event?

  29. Sam

    Ge0rG: sorry, I should have been clear, this is weekly, it just won't let me remove the dates. Ignore everything but the day.

  30. flow

    Sam, when and where is daniels talk tomorrow? ✎

  31. flow

    Sam, when and where is daniel's talk tomorrow? ✏

  32. Sam

    flow: see https://wiki.xmpp.org/web/XMPP_Office_Hours

  33. Sam

    I've asked in the comm room for it to be put out on Mastodon, but if anyone here has access to Twitter it would be good to put it out there too.