XSF Discussion - 2018-09-05

  1. edhelas

    could it be possible to share PEP messages with MUC ?

  2. edhelas

    then I can share my localisation with people in a room for example ?

  3. MattJ

    Prosody now allows you to get PEP items from people in a MUC, but there is no automatic subscription (yet?)

  4. edhelas

    Holger what about ejabberd :) ?

  5. edhelas

    MattJ how does it work ? I need to configure my PEP node for that ?

  6. MattJ

    It would need to whitelist the MUC JID or be open, yes

  7. MattJ

    For "live" updates, I wrote about this 9 (!) years ago: https://blog.prosody.im/multi-user-chat-gets-rich/

  8. edhelas


  9. Zash


  10. MattJ


  11. MattJ

    and this post to the list ^

  12. Zash


  13. edhelas


  14. MattJ

    I implemented it in Gajim, though I'm guessing the patch no longer applies :)

  15. Holger

    edhelas: Hmmm.

  16. Holger

    The point is making stuff available to room members (or occupants?) who are not on my contact list, without making it available world-wide?

  17. Holger

    (Plus anon rooms?)

  18. edhelas


  19. edhelas

    for example in a room where people could share their location or mood

  20. Zash

    Having directed presence count in the PEP access check?

  21. Zash

    Does anyone actually follow https://xmpp.org/extensions/xep-0178.html now?

  22. Zash

    Or ...

  23. Zash

    Really tiny mention of "or fall back to dialback" in there

  24. peter

    Zash: for c2s or s2s or both?

  25. Zash

    Mostly thinking of s2s here

  26. peter

    Also, I doubt that any CAs issue certs with the xmppAddr field.

  27. Zash

    All glory to Let's Encrypt

  28. Zash

    There can be only one! etc...

  29. Zash

    But at least one server offers EXTERNAL even if the cert doesn't match, then expects dialback to be attempted after <{sasl}failure>

  30. peter

    What aspect of XEP-0178 are you wondering about? The interaction with dialback or the core functionality?

  31. peter

    Ah, right.

  32. peter

    Hrm, that seems less than ideal.

  33. Kev

    Zash: Us? I'd say that's a bug. I'd say it's always a bug to advertise external and not have it succeed.

  34. peter

    We might want to take a look at how 178, 220, and 344 interact.

  35. Zash


  36. Zash

    don't forget 288 :)

  37. peter

    Well yeah.

  38. peter

    That too. :-)

  39. Kev

    288 interacts by not having interoperable implementations :D

  40. peter


  41. Zash

    IIRC the rationale was to be able to report certificate validation errors back with the SASL failure, which seems sensible

  42. Kev

    We'll be redoing S2S in M-Link shortly and I'm seriously wondering if there's value in us (re-)implementing 288.

  43. peter

    If we just used the blockchain, this would all be easy. https://medium.com/originprotocol/introducing-origin-messaging-decentralized-secure-and-auditable-13c16fe0f13e

  44. Kev

    Not using blockchain was our second big mistake.

  45. Kev

    Sorry, third.

  46. Kev

    Our second was not using bittorrent.

  47. Zash

    Blockchain based PubSub over BitTorrent!

  48. Kev

    And our first was not using yaml (I assume JSON must be going out of fashion by now).

  49. peter

    JSON is Forever™

  50. waqas

    MongoDB is webscale, etc

  51. waqas

    Kev: A little curious about what "redoing S2S in M-Link" would result in

  52. waqas

    Just a code cleanup, or something beyond that?

  53. Kev

    waqas: Nothing visible, just tidying up some things internally.

  54. waqas

    Got it

  55. Kev

    Well, nothing visible from the protocol side.

  56. Kev

    But enhancing support for our non-Internet type routing scenarios.

  57. waqas

    That sounds neat

  58. Kev

    Yeah, some of this stuff is genuinely difficult and interesting.

  59. Zash

    288 seems like it'd be beneficial for some of those

  60. Zash

    also helps in some cases like where the server is behind a NAT or moving around without updating DNS

  61. Kev

    In those sorts of cases you probably don't want to S2S at all :)

  62. Zash

    read: I like being able to run a server on my laptop and have it work even when I visit people

  63. Kev

    (Probably you want 361 in most of those cases)

  64. Kev


  65. Kev

    Except the 'moving laptop pretending to be a server' case possibly.

  66. Kev

    Although even 288 isn't enough to save you there.

  67. Zash

    Not perfect but it works

  68. Kev


  69. Kev

    I suspect that you'd find that a clustered server would give you partial service, depending on the model.

  70. Kev

    It'd be quite reasonable for a cluster to want one S2S session per node, rather than a giant mesh of session routing.

  71. Zash

    Since I do this mostly to test stuff locally, it only needs to work sometimes, ie when I'm testing.

  72. Kev

    But now I'm vanishing.

  73. pep.

    > Kev> And our first was not using yaml (I assume JSON must be going out of fashion by now). Wasn't yaml a superset of json

  74. Zash

    yaml is a superset of everything

  75. Maranda

    Hmm M-Link and 288 in the same sentence, did Bidi ever work in it to begin with? 🤔😜👹

  76. moparisthebest

    Has anyone ever seen or heard of MAM between different devices connected to the same account?

  77. moparisthebest

    Someone in another muc was surprised omemo didn't work this way

  78. moparisthebest

    (he didn't use those words of course, more like why don't I have full history on new device B when device A has full history)

  79. Link Mauve

    moparisthebest, it’d then be trivial for the server (“the attacker”) to obtain the logs of things it shouldn’t have had access to.

  80. Link Mauve

    At some point we could also drop the act and just implement OMEMO in the server.

  81. moparisthebest

    Link Mauve: well presumably it would reencrypt, but yea still kind of breaks PFS