XSF Discussion - 2020-11-02

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

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

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."

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

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

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.

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

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

Not sure what their status on that is

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

that is what MAXS does if xep33 is not available

On the client side?

yep

As I said, clients don't implement 33

otherwise it would be fine :)

hmm, maybe I did not understood your concern then

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

But they don't do that either

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

The bridge's problem is the lack of client support

Clients only support XEP-0045 groups

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.

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!

Hi all !

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

nad287: why