XEP-0313: Message Archive Management

[Mikaela]

• XEP-0313: Message Archive Management

I didn't see an issue about this, while this is a very important feature at XMPP and I think it can also help Matrix users. What I wish to see:

• [ ] XMPP users get access to room history before they joined the Matrix room if the room history visibility allows it (members only or members since invite)
• [ ] Matrix users see history at XMPP MUC if it's provided (when they are the first user to join there, I think currently the second user joining a XMPP MUC from Matrix can see what the first saw since their join)

[Mikaela]

Would this also help messages getting synced to both directions after the bridge has had problems?

[emorrp1]

This seems to be very much expected for XMPP users, currently the lowest common denominator over the bridge is no better than IRC where you get no context on joining.

[l29ah]

This seems to be very much expected for XMPP users, currently the lowest common denominator over the bridge is no better than IRC where you get no context on joining.

Nah. XMPP bridges for IRC, biboumi for instance, provide returning users with history backlog with XEP-0045, so they don't need to be online permanently or bring up their own bouncer services (while i'm not aware of bouncer solutions for Matrix, so w/o proper bridge-side history support they seem to be out of luck).

[selurvedu]

@emorrp1 modern servers and clients support MAM which lets you fetch history from the server (although some clients don't support MAM in MUCs yet, namely Dino). Also the aforementioned XEP-0045 Discussion History has been here for ages, is supported by every single client and can serve as a fallback when MAM is not available.

[pravi]

We are trying to crowd fund this feature, we found someone to work on this (Outreachy interns who worked on creating yarn plugin to resolve apt installed dependencies in Debian). But we need to find some organizations who can host this campaign as no fund raising platforms we checked supports payments to their country.

See https://social.masto.host/@praveen/106806378856212129 for details.

[l29ah]

Any cryptocurrency-based fundraising platform?

[pravi]

In discussion with xmpp.js maintainers, they think implenting it in matrix bifrost is best option https://github.com/xmppjs/xmpp.js/discussions/920

[pravi]

https://xmpp.org/2021/09/the-xsf-as-a-fiscal-host/ sounds like a good fit for fund raising. @Half-Shot can you register here or should we register it?

[emorrp1]

As announced in TWiM donations are via Open Collective

[maranda]

I don't see much point in implementing this into xmpp.js if you want a MAM interface to query the Matrix room history it has to be implemented in Bifrost. Said that basing on my experience as XMPP developer I see multiple points of criticity ex. that XMPP / MAM wants stanzas to be presented in the same order they're received, while most Matrix APIs tend to order events basing on the graph position and that sync'ing operations in Matrix are performance critical opening to a wide array of possible race conditions. Also MAM enforces the use of stable unique ids for each entry (see: https://xmpp.org/extensions/xep-0359.html) and I see no guarantee that event ids are always unique.

[pravi]

@maranda after discussing with xmpp.js developers we are implementing this as a plugin to xmpp.js and it will need some code directly in bifrost as well. Would it make sense to modify mam spec itself to cover this case?

[maranda]

@pravi I don't think it makes sense to make any changes into spec, even because stream in-order processing is primarily defined into RFC 6120 and hardly that can be changed. More likely you want to make sure that the provided order of archive entries when replying to MAM queries is always consistent XMPP side.

[uhoreg]

... and I see no guarantee that event ids are always unique.

Event IDs in Matrix are unique.

[pravi]

Thanks to @maranda , mam support is now implemented in https://github.com/maranda/matrix-bifrost/tree/aria-net-tls-component and https://aria-net.org/SitePages/Portal/Bridges.aspx has details of the bridge instance. There are also other fixes in the fork and it'd be a good idea to merge changes back.

[Half-Shot]

We're actively taking a look at this now.

[poVoq]

Maybe time to archive this and just referr to the much improved fork?