jdev - 2024-02-12


  1. singpolyma

    I need to make a way to execute commands on MUC participants for cheogram android I guess

  2. lovetox

    Are we still ignoring that IQ in MUCs are a hack

  3. Schimon

    > IQ in MUCs are a hack Good point

  4. MattJ

    lovetox: you'll be pleased to know they're deprecated in the new MUC spec I'm drafting

  5. jonas’

    deprecated?

  6. jonas’

    I thought to-bare-jid is generally needed/useful and you intended to pin that down?

  7. MattJ

    Yes, bare JID stays

  8. MattJ

    But that's not the hacky part

  9. jonas’

    right

  10. pep.

    MattJ, so that's it, we'll have MEP to be able to fetch OMEMO keys? :P

  11. MattJ

    OMEMO keys will work to bare JID, though it's only used in private MUCs where you know the real JID anyway, right?

  12. pep.

    Well it currently works in semi-anon too in prosody

  13. MattJ

    Ah, you mean 1:1 in PMs

  14. pep.

    No in the rom

  15. pep.

    No in the room

  16. MattJ

    Hmm, I guess

  17. MattJ

    Who does that?

  18. pep.

    But maybe also in PMs yeah, sure

  19. pep.

    People who like the abstraction of a MUC not to leak their barejid?

  20. pep.

    I mean, ok I already have 5-6-7 accounts, but it's a bit of a pain to handle tbh

  21. MattJ

    I mean, who does E2EE in semi-anon MUCs?

  22. pep.

    > pep.> People who like the abstraction of a MUC not to leak their barejid?

  23. MattJ

    Okay, but I guess I mean clients

  24. MattJ

    Not people

  25. jonas’

    stop

  26. jonas’

    you're talking past each other

  27. MattJ

    Good to know :)

  28. jonas’

    pep., it will continue to work, AIUI will MUC 2.0-by-MattJ route all IQ requests to the bare JID without you needing to know the bare JID.

  29. jonas’

    that is sufficient to retrieve OMEMO keys

  30. pep.

    Well I would prefer MEP nonetheless I think, so noone reaches my barejid when I haven't consented to it, I guess. But ok

  31. MattJ

    Right, yes, I got that, and I answered that (maybe not clearly enough)

  32. jonas’

    yep

  33. pep.

    I didn't get this part indeed

  34. MattJ

    But my questioning about OMEMO in semi-anon was separate, because I'm not aware of clients that support this

  35. jonas’

    now that that's sorted, you can continue to discuss the future ideal protocol

  36. pep.

    MattJ, well none atm indeed..

  37. pep.

    Unfortunately

  38. MattJ

    Okay

  39. MattJ

    Which makes sense, because E2EE with strangers generally does not make sense

  40. Zash

    Opt-in flag somewhere for PMs or IQ routing?

  41. pep.

    MattJ, "it depends"?

  42. pep.

    What's a stranger? :)

  43. Zash

    Wait are we still formulating the problem? If so ignore that

  44. MattJ

    More like "Who's a stranger?" - you can't identify the identity of someone who is unknown to you, so you'll never be able to rule out MITM on the E2EE layer

  45. MSavoritias (fae,ve)

    the whole contact flow for sending a message is bothersome i agree

  46. MSavoritias (fae,ve)

    maybe they should be seperate

  47. MSavoritias (fae,ve)

    but i think thats ui issue imo

  48. moparisthebest

    > Which makes sense, because E2EE with strangers generally does not make sense Russian spammers that start all messages with ?OTR seem to disagree

  49. pep.

    MSavoritias (fae,ve), cooptation generally works good enough

  50. jonas’

    :D

  51. pep.

    MattJ, ^

  52. jonas’

    cooptation?

  53. pep.

    coptation?

  54. MSavoritias (fae,ve)

    yeah what is that

  55. pep.

    franglish?

  56. jonas’

    coptation?

  57. pep.

    https://www.wordreference.com/fren/cooptation both exist.

  58. pep.

    invites

  59. pep.

    I don't need to know who's who as long as there's a chain of trust

  60. jonas’

    does that "cooptation" include the OMEMO keys of all those on the other end of the chain?

  61. MSavoritias (fae,ve)

    social chain of trust?

  62. pep.

    MSavoritias (fae,ve), yes

  63. pep.

    jonas’, not sure I understand

  64. jonas’

    pep., I don't get how invites play a role in the security of E2EE

  65. pep.

    I'm not talking technical here

  66. jonas’

    unless they include OMEMO fingerprints of all participants.

  67. jonas’

    ah

  68. jonas’

    ignore me hen

  69. jonas’

    ignore me then

  70. moparisthebest

    Plus encryption without authentication is still valuable because you can authenticate later and it still hides the content from servers that aren't yet evil (aren't already doing active MITM)

  71. MSavoritias (fae,ve)

    isnt PMs in mucs a "hack" tho

  72. MSavoritias (fae,ve)

    i have heard they are not exactly a good technical solution

  73. pep.

    Not really related to the current chat, but yeah, ish

  74. MSavoritias (fae,ve)

    ok

  75. pep.

    I guess what's annoying really is that there are things you can't do in PMs that you can do in regular 1:1. That's.. both a feature and a bug? :/

  76. MSavoritias (fae,ve)

    the whole concept of PMs in group chats as is its confusing

  77. MSavoritias (fae,ve)

    as it is currently

  78. pep.

    What is

  79. MSavoritias (fae,ve)

    that i can message a person directly but its actually not the person its the group chat i am messaging. and its not actually directly because all the group chat restrictions apply. and the ui is either seperate like gajim or combined like conversations. both of them confusing for different ways

  80. Holger

    > I guess what's annoying really is that there are things you can't do in PMs that you can do in regular 1:1. That's.. both a feature and a bug? ... like sending a message when the peer lost the TCP connection?

  81. pep.

    Holger, that's a feature of MUC? :P

  82. pep.

    (Well PMs are too, but..)

  83. Holger

    Well for plain MUC the recipient can at least catch up using MAM.

  84. wgreenhouse

    it would be nice if people with registered nicks or persistent occupant id could get muc pms while disconnected

  85. wgreenhouse

    (analogy to irc memoserv)

  86. singpolyma

    registered nicks would be pretty easy to make work

  87. singpolyma

    though I'd rather limit PMs to saying "/me wants to chat with you: xmpp:itme@example.com"

  88. Zash

    Awkwardness would occur if you have a subset of your online clients in the room

  89. Zash

    MUC PMs and MAM is also awkward, unsolved still I think?

  90. singpolyma

    they're "just" type=chat messages so they go in mam like normal AFAIK

  91. Zash

    They do not beacuse of <{muc}x/>

  92. Zash

    Maybe? I'd have to review XEPs and code to bes ure

  93. Zash

    Maybe? I'd have to review XEPs and code to be sure

  94. lovetox

    They do zash

  95. lovetox

    Problems with MUC PM where solved when clients iclude the <x{muc}>

  96. lovetox

    Its still a problem with clients that do not include that

  97. lovetox

    MattJ, i have great hope for your XEP, if i can make one wish, please make everything as explicit as possible

  98. lovetox

    will it be something completely new or something that is somehow backwards compatible

  99. MattJ

    Indeed

  100. MattJ

    The goal is that it will be similar enough to MUC that existing implementations (client and server) won't find it hard to switch, or support both at the same time

  101. MattJ

    So legacy MUC clients and new MUC clients can both join the same room, and just see different views of the same thing

  102. MattJ

    Many things are already in place, either as implementation or specs, but it's not clear how to put them all together to get a good experience for users and developers

  103. MattJ

    So the new spec is mostly about that

  104. singpolyma

    MattJ: ... you mean it's not going to be drop in compatible? :P

  105. MattJ

    If you want that, XEP-0045 is there for your convenience :)

  106. singpolyma

    but why make a new thing if it's not going to be compatible?

  107. MattJ

    Because it's compatible enough to not be a complete rewrite :)

  108. Wirlaburla

    I imagine we could just add a module to servers for full backwards compatibility with clients then.

  109. lovetox

    anyone aware of a server that reponds with a message error "recipient-unavailable"?

  110. lovetox

    the user told me the message was received anyway

  111. singpolyma

    that happens when sm fails to confirm delivery

  112. singpolyma

    but then it probably went into mam anyway

  113. lovetox

    but thats a bug or?

  114. lovetox

    why would i care if sm fails to confirm something

  115. lovetox

    why do i care if a recipient is unavailable to the server

  116. lovetox

    thats like his problem not mine

  117. lovetox

    we dont have somekind of message acknowledge thing going

  118. lovetox

    MUC XEP Note: A message with a <subject/> and a <body/> or a <subject/> and a <thread/> is a legitimate message, but it SHALL NOT be interpreted as a subject change. Same XEP Note: In accordance with the core definition of XML stanzas, any message can contain a <subject/> element; only a message that contains a <subject/> but no <body/> element shall be considered a subject change for MUC purposes. What is it now :D

  119. lovetox

    ^ MattJ another nice example for making things explicit

  120. lovetox

    ^ MattJ another nice example for making things not explicit

  121. lovetox

    In general i think the rule is good, as a client dev i want to look at a single xml element to decide the code path

  122. lovetox

    usually we do this quite good, when we use namespaces

  123. lovetox

    the worst example of that is this fucking table

  124. lovetox

    https://xmpp.org/extensions/xep-0077.html#table-3

  125. dwd

    > anyone aware of a server that reponds with a message error "recipient-unavailable"? Ooooh... Yeah, I've seen this. Given a server with '198 and no support for offline messages, and a user with one device online and one with a connection severed, messages can end up hitting the dead session, timing out, and being bounced. Cannot remember which server (or server version) it was though.

  126. dwd

    Definitely a server bug though.

  127. moparisthebest

    > the worst example of that is this fucking table oof that hurts my brain *closes tab*

  128. singpolyma

    dwd: it used to be the normal behaviour for smacks, but at some point it stopped being so I don't see it often now I guess

  129. dwd

    > the worst example of that is this fucking table At least there *is* a table there, instead of it just being dense prose which covers only half the cases and you're expected somehow to know the whole picture.

  130. moparisthebest

    that is true, though best case would be removing the need for either

  131. dwd

    Sure. But given the choice of "well designed" and "well documented", I know which I'll pick first.