[Feature Request]: "Share via" Meshtastic -- designs to allow third-party apps to send and receive data

[rndmcnlly]

Contact Details

No response

Tell us your idea.

We all want to see the Meshtastic ecosystem thrive, but we're mostly sending simple text messages about the mesh itself right now. This feature request is the start of a pathway to growing an ecosystem of apps that build around Meshtastic without hiding the fact that they use Meshtastic for transport.

I'd like to be able to create small apps that communicate through the main Meshtastic Android app rather than replacing it.

Problem

Consider the Mesh-tac-toe app from Spec5. Even though the app focuses on the tiny use case of playing tic-tac-toe, the app needs to be complicated enough to pair/unpair radios. You can't use this app and our main Meshtastic app with the same radio at the same time. We need a different design pattern for apps so they don't need to compete for exclusive radio access.

Spec5 is already facing this problem as you can't use Mesh-tac-toe at the same time as their own other Mesh chess app. It is bad enough that third-party apps need to compete with the community app, and it is worse that third-party apps (even from the same developer!) compete with each other.

Solution

Think about how specialized apps can let you share content via the user's preferred email app. At the same time, when you get a strange attachment in the email app, you can open the attachment in specialized apps. On Android, this mechanism is typically implemented using intents. (background reading). Let's think about how to main Meshtastic app can broadcast and listen for intents on the local device so that multiple apps can share access to whichever radio is currently paired and configured in the main app. Below, I offer some low-tech alternatives that don't even require creating new intents, but they require more work for users (but maybe that's okay for the current Meshtastic audience that emphasizes tech-oriented early-adopters).

If we follow the pattern of concentrating technical configuration in the main app, other apps get simpler, and our ability to centralize documentation/guides improves. It also further insulates third-party apps from technical changes to low-level Meshtastic details.

Approaches

I don't have a worked-out design for us read to implement, but here's are some sketches. Common to both all is that the API hides device-specific details. If the user needs to change settings like the LoRa preset, the channel keys, or whatever, they should only do that in the main Meshtastic app, not any of the apps collaborating with it.

Active designs

In these designs, other apps can send/receive data through the main app instantly without the user needing to take additional actions. These probably provide better experiences for users while being more tedious for app developers to integrate. These design would allow other apps to show useful notifications to the user when actionable data was just received.

Low-level Intents

When the main app receives a packet, it should also issue a broadcast intent for com.meshtastic.RECEIVE_PACKET, attaching whatever technical detail is available (e.g. anything you'd see visible in the current "Debug Panel" page).

The main app should listen for intents for com.meshtastic.SEND_PACKET and make a best effort to send the attached data.

High-level Intent

When the main app receives a packet, it should issue a broadcast intent for com.meshtastic.RECEIVE_MESSAGE, somehow including the portnum in a way that apps can register to only listen for messages associated with their specific portnum.

The main app should listen for intents for com.meshtastic.SEND_MESSAGE and make a best effort to send the attached data. To make it easy to address messages to specific nodes/users, the main Meshtastic could expose a view of the NodeDb as a content provider component.

Passive designs

These designs require less technical documentation and integration effort, but they require the user to take more actions each time a message needs to move around. There's a chance that users will find pre-existing apps that play nicely with the design, giving them new abilities without any coordination between developers. In these designs, it is the user's responsibility to notice that a new message might be usefully opened in a different app without any clues from notifications.

Sharing Intents

When someone long-presses on a packet in the debug panel, they could be given to "Share" the data to another app via however sharing of binary attachments works in Android.

Going in the other direction, if someone selects data in a different app and decides to "Share" it via Meshtastic, the Meshtastic app can give them a lightweight and generic Compose message screen that results in sending a low-level packet. The user could be given the option to customize these details:

• portnum: This defaults to TEXT_MESSAGE_APP (1). However, the user should be able to pick a customized value (perhaps restricted to ones that won't collide with previously registered portnums). If the incoming sharing intent has provided a portnum, this would be used to override the default.
• channel: This defaults to 0, can be overridden by the incoming sharing intent, but could be configured by the user to be any one of the channel's they've configured already.
• destination: Defaults to !ffffffff but can be overriden or user customized, perhaps using a picker or search widget connected to the NodeDb.
• payload: User gets the choice of using the sharing intent's text attachment as plain text (best paired with TEXT_MESSAGE_APP) or as raw binary data. Perhaps some information in the sharing intent's mimetype can give us a good default.
• (anything else that should obviously be included, assuming we can provide good defaults)

File Attachments

Forget about intents. From the debug panel, let users save the payload of any packet as a file (perhaps letting them customize the filename and mimetype). Later, they can use and other app to attempt to load this file without caring that it happened to have been produced by the Meshtastic app.

To allow people to send messages, create a new Compose message screen (like the one sketched in the previous section), but have this allow them to select a file to be used as the binary payload (and warn them if the payload would be truncated to fit the outbound packet).

This design gives you extreme flexibility. For example, people could write custom code in Python that runs inside of the Termux app to pack and unpack packets before communicating them as raw binary attachments in the Meshtastic app. At the same time, it would be pretty tedious to send even a hello world message through this mechanism.

Even if users never utilize this mechanism, it could help in-the-field debugging of the main app itself.

Recommendations

Let's start with the File Attachments design above. This would allow us to make a proof-of-concept app (perhaps tic-tac-toe) that demonstrates the idea of communicating through the Meshtastic app without replacing it.

Once people have seen the concept, we could then implement the Sharing Intents design to make the previous app slightly easier to use. At this point, people may realize which pre-existing apps people want to use via Meshtastic. At this point, we could try to get the iOS app in sync by using the iOS version of sharing intents (something about share sheets that I don't personally understand).

After we have better ideas of how people want to build around Meshtastic, we'll have the wisdom needed to debate variations on the Low-level Intents and High-level Intents designs above. In order to make the design not overly specific to Android or iOS, we might look into the mechanism of custom protocol handlers supported by most many modern operating systems and web browsers. (We've long been able to open the user's email app by writing out mailto: URLs. Perhaps we can have a kind of meshtastic: protocol that is interpreted by the user's chosen local app.)

Next steps

• Add "Save payload as file" context menu item for each item visible in the debug log screen.
• Add "Send" button (next to "Clear") in the debug log screen, allowing the user to craft a low-level packet using an existing file as the payload source.

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct

[jamesarich]

There is already some of this built out in the IMeshService - check https://github.com/meshtastic/Meshtastic-Android/blob/master/app/src/main/aidl/com/geeksville/mesh/IMeshService.aidl