XSF Discussion - 2020-11-02

  1. flow

    deuill, consider using exinsting code where possible, e.g. one of the plenty XMPP libraries

  2. flow

    deuill, you definetly don't want to implement an xmpp stack from scratch

  3. deuill

    Indeed yeah, I'm planning on using https://mellium.im. My question is more about getting a good world-view on which I can build the semantics/interface which I'll use to bridge over to Delta, questions like "What is an account? What is a direct message? What is a group, and how do users in groups differ to ones messaged directly? etc."

  4. deuill

    I've previously built a small chat-bot that utilizes Inform7, but the semantics there are easier to bridge: https://github.com/deuill/informbot

  5. deuill

    I realize bridges are the sorts of rocks that lots of ships have crashed against, but ehm...

  6. deuill

    XEP-0100 is probably a good starting-point, I wish it covered MUC etc. but it should be straightforward to draw a line from in any case.

  7. deuill

    And AFAIK there’s no such thing as a transport framework/baseline for XMPP, at least not one in Go (Matterbridge doesn't count)

  8. MattJ

    deuill, I'm not sure how Delta Chat handles groups exactly, but I'm going to assume it's more akin to XEP-0033 than XEP-0045. The problem is that the former is not implemented by clients. You may find some companionship in the JMP community where they have the same problem for group SMS bridging, and have been looking at solutions and MUC<->-0033 bridges

  9. MattJ

    Not sure what their status on that is

  10. flow

    MattJ, can't one have pseudo xep33 by simply forking the messages?

  11. flow

    that is what MAXS does if xep33 is not available

  12. MattJ

    On the client side?

  13. flow


  14. MattJ

    As I said, clients don't implement 33

  15. MattJ

    otherwise it would be fine :)

  16. flow

    hmm, maybe I did not understood your concern then

  17. MattJ

    Well what you're saying is that they should essentially implement pseudo-33 on the client side

  18. MattJ

    But they don't do that either

  19. MattJ

    Your suggestion is a workaround for lack of server support, which isn't a problem in the case of a bridge

  20. MattJ

    The bridge's problem is the lack of client support

  21. MattJ

    Clients only support XEP-0045 groups

  22. deuill

    MattJ, hmmm from reading the Delta Chat library code, it seems you're right -- "group chats" aren't given their own IDs so there's no one-to-one mapping to a JID per se, though it might be perhaps possible to fudge support with some intermediate state in the transport.

  23. deuill

    I guess the issue then is synchronizing state for out-of-band changes, but I'll get there. I appreciate all your input and help!

  24. nad287

    Hi all !

  25. nad287

    Can we change omemo to use AES CBC instead of AES GCM ? or omemo protocol force to use AES GCM ?

  26. moparisthebest

    nad287: why