Feature Request: Message Archive Management
Greetings,
I was wondering if there were any plans to support XEP-0313. I found an issue dated back in 2014 where an issue was tagged as a feature for a Milestone but later removed so I was wondering if Profanity would get support for that in the future. Thanks in advanced!
Definitely something I'd like to add, just need to find the time.
XEP-0313 is an improvement over XEP-0136 which was requested in #264 .
Could this be implemented as a plugin?
Without having looked too deep into the XEP my guess is the plugins API probably doesn't yet have enough to be able to implement it.
I could be wrong though, some investigation into the XEP and an overview of the flow of stanzas and UI operations would help.
Anything new here? It's been two years almost..
Not had a look at this feature yet, it's quite a large one and others have taken priority.
I would like to add it in the future though.
@boothj5 ping :)
Together with Message Carbons, this would make for a perfect console client. Following :)
https://github.com/profanity-im/profanity/pull/1306 with basic MAM support has been merged.
Only contains basic support. More work is planned and needed. Don't enable it yet if you don't know what you are doing. Only for devs.
Some more TODOs after #1413
- RSM (so far we only get a couple of messages from the archive)
- think about how to properly use it
- from db vs from MAM
- add user setting to enable/disable MAM
- receive based on last ID or date?
- how to update the buffer in case we want to scroll upwards to load more messages?
Several points from https://github.com/profanity-im/profanity/issues/660#issuecomment-663019913 still need to be done.
However, git users can now have the following working:
/mam on will enable MAM.
/msg myfriend will open a window and send a mam request. All messages from the last 7 days should be fetched and displayed.
It doesn't happen if a user writes to you and the windows is opened that way. (we need to think about how to sort the messages) It also could be that messages are duplicated displayed if you have loading from history enabled (still the sorting/updating).
I'm thinking whether maybe we should from now on not print anything to the window directly anymore. But instead put everything into the SQLite DB. Then trigger a refrsh if messages for a certain window were recevied. And we get the messages always from the DB. Then they could always be sorted by sqlite, and we might use ProfBuff for chaching for ProfWindow.
Thoughts?
We have most of this figured out already. But look over: https://github.com/modernxmpp/modernxmpp/commit/cd3e871e55c2cff45dffd05d6e50380b99845849 again when implementing the rest of MAM.
We have most of this figured out already. But look over: modernxmpp/modernxmpp@cd3e871 again when implementing the rest of MAM.
Along with this thread: https://mail.jabber.org/pipermail/standards/2021-August/038483.html
When implementing MUC MAM we need to tell the MUC that we dont want to get MUC history upon joining anymore.
https://github.com/profanity-im/profanity/pull/1724 got merged! MAM in 1:1 support WITH infinite scrollback (reloading from DB) is now done. Thanks a lot to @MarcoPolo-PasTonMolo for implementing this!
Todo:
- test (from 21 oct 22 to 11 jan 23 nothing was found)
- check if autocompletion / quoting works https://github.com/profanity-im/profanity/issues/1770
- check if plugin api still okay
- implement MUC MAM
Also maybe trigger fetching mam when connection gets re-established. Be careful though because if a new message is received before the mam request gets triggered messages that were sent whilst connection was down might get lost
@MarcoPolo-PasTonMolo are you maybe in the mood to take a look at MUC MAM?
Sadly no. I'm starting to get busy again