Meshtastic-Android
Meshtastic-Android copied to clipboard
[Feature Request] Ability to send images
I understand that Lora is inherently low bandwidth and each message has a limit of about 200 bytes. But what if we took an image and split it into pieces equal to 200 bytes then sent the pieces one by one and then reconstructed it on the other side? What do you all think?
i think sending text files like a .txt would be far more useful. for example in an emergency network. sending list of missing person names, item list and stuff.
they would need to implement integrity checks to insure all the text is received intact.
I understand and agree. I tested the Python API by sending an image, and it took a very long time, even after I attempted to compress it. I believe you don't need to add any extra checks for data integrity, as Meshtastic already has that feature built-in. However, what I would suggest is simply labeling the packets, like 1/10, and if you're missing packet 9, you can ask the sender to resend it.
i think it should do this automatically, i do not believe bothering the user to manually check is a good thing. the software should try and gather the complete thing from the moment it start the transfer. as conditions/positions might be changing it might not be possible to reach the same station later on.
but yes, being able to send text files would be greatly loved by some people. the problem is that it might only be possible to do between node that are connected to a cellphone. i dont know how much memory there is available on each individual node. will repeaters be able to store and "bounce" this data?
Packets could be sent one at a time, no need to buffer anything on repeaters. I'm guessing in practice you'd mostly want to send only 1 packet every few minutes, so you didn't clog up a channel.
This could be used for very small SVG avatars and user profile pages, and one frame a week webcams would still be very interesting.
Files could have headers with a version, hash, and timestamp, so two people sending identical files wouldn't repeat the same data, and you could push new versions of the same file for webcams and living documents.
Other nodes that already have a file could pick up where the previous sender left off, if the hashes match.
And you could just advertise the header until someone actually replied, so files without interested receivers don't waste data.
I think there's a lot of applications even with transfer times measured in days at 1% duty.
any feature with the potential to freeze the entire mesh needs to be carefully considered before going into production. closing for now.