Progres Report
Published on March 25, 2022 by Nkwuda Sunday Cletus
Hi folks.
We are sincerely grateful for your generous contributions and support towards this project .
I'm deeply sorry that your support has not been reciprocated by good progress on my side, especially for my inability to deliver progress updates on the timelines that I've given in the past.
This project is pretty much like "fixing a bug", and such we all know one can't give a definite timeline, as what you think might take a week might just end up taking several weeks to resolve.
It's quite intuitive that matrix-bifrost, when used as an appservice bridge, on a matrix server handles both connecting a matrix room to the matrix service and also connecting the room to the xmpp service specified in the room url. But what is not clear to me is what handles "the joining of a matrix room from xmpp". Does supporting xmpp servers use a kind of matrix-aware xmpp component or there's a client-side xmpp feature to handle that. I guess a matrix-bifrost appservice bridge connected to a matrix server somewhere wouldn't ordinarily control how an xmpp server elsewhere handles room joining requests, and a baremetal xmpp server wouldn't ordinarily understand a matrix-formatted room jid ( and for a nonexistent room for that matter ) . Please, I'd appreciate any clue on how this works.
I have tested with 3 different xmpp clients and realized I'm not able to join a matrix room from dino and gajim whereas I'm able to join a matrix room from Conversations and vice versa.
CURRENT SCOPE OF THE CHALLENGE
From my test with Conversations jabber client:
-- For a room created on the xmpp app, a user can join from matrix without any MAM issues on both sides
-- For a room created on Matrix side, a user can join from xmpp app, but only the matrix side recieves offline messages whereas the xmpp side do not recieve messages sent while offline . The xmpp user will still see older messages but won't see the ones sent while he was offline ( hence we can say there's partial MAM )
NEXT STEPS
-- Having set up development environment for Conversations, I am going to try a local instance of prosody server with conversations and see how it works. Basically, I'll have local instances of synapse+bifrost, prosody, and Conversations app.
-- I am currently going through every peice of matrix-bifrost source code as there are no documentations for it but I need to understand it thoroughly to be able to tweak it. I've realized that it's heavily-dependent on xmpp.js and matrix-appservice-bridge ( https://github.com/matrix-org/matrix-appservice-bridge) which is itself dependent on matrix-appservice-node ( https://github.com/matrix-org/matrix-appservice-node ) . Hence I also needs to understand xmpp.js, matrix-appservice-bridge, and matrix-appservice-node.
SUMMARY
-- I still have to work with a lot of APIs and libraries to be able to figure out a fix. I have no idea how long this may still take, as I'm also combining it with other engagements, but I'll work very hard to have a solution sooner than later.
We are sincerely grateful for your generous contributions and support towards this project .
I'm deeply sorry that your support has not been reciprocated by good progress on my side, especially for my inability to deliver progress updates on the timelines that I've given in the past.
This project is pretty much like "fixing a bug", and such we all know one can't give a definite timeline, as what you think might take a week might just end up taking several weeks to resolve.
It's quite intuitive that matrix-bifrost, when used as an appservice bridge, on a matrix server handles both connecting a matrix room to the matrix service and also connecting the room to the xmpp service specified in the room url. But what is not clear to me is what handles "the joining of a matrix room from xmpp". Does supporting xmpp servers use a kind of matrix-aware xmpp component or there's a client-side xmpp feature to handle that. I guess a matrix-bifrost appservice bridge connected to a matrix server somewhere wouldn't ordinarily control how an xmpp server elsewhere handles room joining requests, and a baremetal xmpp server wouldn't ordinarily understand a matrix-formatted room jid ( and for a nonexistent room for that matter ) . Please, I'd appreciate any clue on how this works.
I have tested with 3 different xmpp clients and realized I'm not able to join a matrix room from dino and gajim whereas I'm able to join a matrix room from Conversations and vice versa.
CURRENT SCOPE OF THE CHALLENGE
From my test with Conversations jabber client:
-- For a room created on the xmpp app, a user can join from matrix without any MAM issues on both sides
-- For a room created on Matrix side, a user can join from xmpp app, but only the matrix side recieves offline messages whereas the xmpp side do not recieve messages sent while offline . The xmpp user will still see older messages but won't see the ones sent while he was offline ( hence we can say there's partial MAM )
NEXT STEPS
-- Having set up development environment for Conversations, I am going to try a local instance of prosody server with conversations and see how it works. Basically, I'll have local instances of synapse+bifrost, prosody, and Conversations app.
-- I am currently going through every peice of matrix-bifrost source code as there are no documentations for it but I need to understand it thoroughly to be able to tweak it. I've realized that it's heavily-dependent on xmpp.js and matrix-appservice-bridge ( https://github.com/matrix-org/matrix-appservice-bridge) which is itself dependent on matrix-appservice-node ( https://github.com/matrix-org/matrix-appservice-node ) . Hence I also needs to understand xmpp.js, matrix-appservice-bridge, and matrix-appservice-node.
SUMMARY
-- I still have to work with a lot of APIs and libraries to be able to figure out a fix. I have no idea how long this may still take, as I'm also combining it with other engagements, but I'll work very hard to have a solution sooner than later.