Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this page for instructions on how to get full permissions. Sorry for the inconvenience.
I am not sure about most of the work being here over ModemManger. The glue from here to MMSD will be required. However, MMSD uses the WAP Push API of ofono. ModemManager has no API for that. It would be possible to create a dummy plugin to MMSD and send the data to MMSD from purple-mm-sms, but that is not really a proper solution because MMS is a small subset of all possible push notification types. It does not really make sense for purple-mm-sms to be handling push notifications for applications that have nothing to do with chat.
I've pushed some code to at least display the notification. Viewing the contents of the actual message is another story. push-notify
Don't get me wrong. I'm all for putting something together that gets the job done asap. I started three times on creating an MMSD plugin.
First attempt was to mirror the ofono plugin. That is when I realized that ModemManager is missing the bits required for MMSD to register itself as a WAP Push recipient, as ofono does.
The second attempt was to mirror the purple-mm-sms plugin and remove the purple bits, Thinking I might create a MM-MMSD-purple chain. There I realized that MMSD knows nothing of SMS. An SMS has either text, or data property. purple-mm-sms only looks for the text property. The branch I linked above grabs data also to show the user what is trying to be sent.
The third attempt is to create a dummy plugin that knows nothing of contexts or bearers, cause neither do I, and exposes a dbus method to receive the information required for mmsd:/src/service.c: mms_service_push_notify(modem->service, data, data_len), which mostly uses service->identity. Then create the uplink / downlink connections in purple-mm-sms. That looks promising, but I know it's not proper.
So, before I go any further on that I was going to see about getting the ofono stack up and running. Then possibly running along side modemmanager. If that works it should be possible to start work on MMSD <> purple.
I've also been working in this space, but mostly on the ofono side, trying to update ofono support in parts of the Purism stack and integrate MMSd. I've collected some info on setting up the Ofono stack here, here, and in this bug tracker.
I don't think it's feasible to have ofono and ModemManager running side-by-side. I looked into integrating MMSd with ModemManager just a little bit, but you look to have gone further than I did so what I wrote there may not be helpful.
@anteater, thank you for reaching out here. I have your patched versions of ofono & mmsd installed. I am working on vgmms, but I don't have a rust cross-compiler set up so it is taking ages in a qemu container. I can see mmsd connect to ofono though. What I can not confirm is that ofono is working properly. I'll post a separate issue on your sr.ht.
I don't doubt that ofono & modemmanager would cause problems if you look the wrong way. My thought though was that if only one service listens and deals with certain types of events it might be enough for a proof of concept.
I've disabled MM & chatty. I am starting ofono manually as a start. I also have the telepathy-ofono stack installed and seemingly ready to go once I get ofono figured out, which appears to be a udev issue at first glance.
I've made some headway on this. There is still a lot of work to do, but at least the signals are connected for getting data to and from MMSD on the receiving end.
MMSD was implemented using a 'simple' plugin. This is a fill in for a proper modemmanager plugin, which would handle contexts and such.
What's not working:
Sending & displaying of content, including group chat. At present, there is a placeholder message sent to libpurple indicating the subject and content type of attachments.
There is no mobile-broadband-provider-info wired in yet so it is necessary to set such information at compile time [here]. Something I'm not sure of is if MM could use any of that information. If not, it could be implemented in the mmsd plugin. oFono handles this directly though.
@fuzzy7k I just saw this, this is great work! If I wanted to get started with helping your mmsd, what would be useful to you?
I am also wondering if the glue you need for the WAP notification could just be wrapped up in a CURL command for now. That was enough for me to send out an MMS via Modem Manager.
@kop316, if you could look into the sending side of things, that would be great. I have done 0 investigation there. I would imagine that MMSD will post the MMS and spit out a SMS WAP notification somewhere internally that should be handled by the MMSD plugin. For now we should probably kick that back to purple-mm-sms so we can use the MM sending capabilities there. By all means though, use your current work and fill in around it.
We'll also need to differentiate between SMS and MMS in the purple plugin.
@fuzzy7k So you know, from what I can tell mmsd does not need to make an SMS WAP notification. it does have to make the encoded MMS (PDU) at some point though (it is a m-send.req PDU , and that is what is HTTP POSTed up to the MMSC). The MMSC will handle making the SMS WAP.
What seems to make the most sense is to have it create the PDU and have it create it as a binary (for debug) or be able to HTTP POST it. I don't know how much it needs to talk to the modem manager for that, if at all? It just needs to know how to reach the MMSC.
@fuzzy7k I just managed to send an mms purely with your mmsd repo!
I compiled with the mmsc set in the code and ran it. Then I was able to just use the dbus SendMessage method thats exposed by mmsd.
So I don't think theres anything that needs to be done with this from the plugin side.
@fuzzy7k As I understand it, purple-mm-sms already uses the dbus to look for incoming SMS messages from modem manager. I would have to look but based on the behavior I see, it ignores SMS WAP notifications (which to me means there is logic already in purple-mm-sms to understand an SMS WAP notification, itjust doesn't do anything for it). So there could be two ways to handle this:
Rather than purple-mm-sms see and then ignore the SMS WAP notification, it invokes mmsd to handle it, or
mmsd uses the dbus to look for the MMS WAP notifications.
Would the first one be simplier? That may remove the need to handle/rewrite a lot of dbus logic for mmsd.
Set the mmsc and any other carrier settings in 'simple.c
compile mmsd, I had to remove '-Werror' from the CFLAGS entry in the Makefile for gcc to allow me to compile. And also when configuring add --enable-debug to ./configure
Run mmsd as a user not as root, I recommend with --no-daemon and --debug so you can watch it happen or fail.
I used pydbus for this, but I realized that mmsd has test scripts already written that you can use. So you can just run test/send-message. All data that you send has to be in a file.
Example:
echo "MMS WORKS!" > text.txt
python test/send-message --help will show you how to format a message
@fuzzy7k Have you done any work in purple-mm-sms for sending mms? Because I have some experience with c and libpurple, so I might be able to help with that. Or if theres anything else let me know.
One part that still needs to be worked out is the libpurple conversation. There are two ways to classify them, a 'IM' and a 'conversation'. Conversations are needed for group chat. It might make sense to convert all messaging within purple-mm-sms to conversations. That needs some discussion with Purism devs though. I'm going off recollection here, so pardon for any innacuracies and brevity.
I think chatty can handle both. When I enable purple-matrix I get the option to create a new message or new group message. And I assume the former is an IM and the latter is a conversation.
NVM I just checked and purple-matrix treats everything as a conversation chat even for direct messages. While purple-mm-sms uses only conversation IM's. That makes more sense for matrix though since everything is considered a room in matrix, so it wouldn't make sense to distinguish. I'm not sure if if makes sense for purple-mm-sms to do the same, since there is a difference between direct message(sms) and group message(mms).
When I was looking at it I recall there not being any benefit to an IM that SMS could use(e.g. typing notification, file transfer). SMS's aren't inherently "instant" either.
The part that convolutes it, and the reason I suggest all conversations be 'conversations' is that not all MMS are group messages and not all direct chat are SMS.
Overall I think it would simplify this plugin without any loss of functionality.
Oh yeah I didn't think about that, I'm not sure if purple lets you combine Chats and IMs. So I don't think using the IM api is even an option here. So chats are most probably the way to go.
I think this is going to require some more work on chatty then, because I see a lot of places in the chatty code that checks for purple-sms and uses the IM api for it.