search

liamcottle / reticulum-meshchat

A simple mesh network communications app powered by the Reticulum Network Stack.
https://meshchat.app
MIT License
134 stars 10 forks source link

Persistent message history #1

Closed RFnexus closed 5 months ago

RFnexus commented 5 months ago

A useful feature would be the ability to retain messages upon page refresh. One approach could be by using localStorage which is supported by nearly all browsers.

One drawback to the localStorage approach is the user must give permission to the page to use localStorage. And localStorage is treated as sessionStorage in private windows.

Another method would be to save the messages to a file through web.py, similar to how NomadNet does it in the /storage/conversations path.

liamcottle commented 5 months ago

Hey! Thanks for opening this issue.

I've pasted my comments on this from the Matrix Chat for reference.

For persistence, my initial thought is a sqlite database, hosted and managed on the python side. There will be tables for lxmf_messages etc, which would allow for an http api or the likes, for fetching the message history in a paginated way from the web ui.

Regarding another comment I saw on storing it in localStorage on the browser side, I have done this in another project (not mesh related), but it was for storing local chat history. Unfortunately, the browser has a very small limit on how much data you can stuff into a single key in localStorage. I found that after about 30 messages were stored, I could no longer store anything else.

Another issue with browser side storage, is if you run the web ui server on one machine (such as on your phone, it does work on Termux for Android, I tested), and then access from your pc any messages saved there will not be available if you decide to access the phone from a different pc in the future.

I have implemented SQLite database support, and this is being worked on in the feature/database branch.

At this time, all incoming and outgoing LXMF messages are saved to the database. Including all of the attachments/fields, which are just JSON serialised. It may become an issue in the future if lots of large attachments are stored in the database, however as a first pass I think this will be fine to keep the implementation simple.

Do note, if you decide to use this branch, since I'm still working on it, there likely won't be any database migrations until it gets merged into master. So the database may need to be deleted/recreated if I change the schema, otherwise it'll complain about missing columns etc.

A useful feature would be the ability to retain messages upon page refresh.

This is all working now in the database branch :) Hoping to merge soon, but want to make sure I'm happy with the schema first.

liamcottle commented 5 months ago

This has been pushed to master branch :)