[Feature] Propose http(s) socket to send SMS

[mdeweerd]

The app could also become an outgoing SMS gateway for local setups (local WiFi network) by proposing a HTTP(s) socket interface to send an SMS.

For security this functionnality could be secured by:

• Use of a token;
• Enabling SSL;
• Only enabling the socket on a selected IP (when it is assigned by the DHCP service);
• Use of TOTP (in addition or replacement of the token);
• Limit the outgoing SMS's to a limited set of number (e.g. define the number prefix(es) to limit to certain countries, areas and phone numbers.

[Pheromon]

I would love this feature!

[rockstorm101]

On the other hand, I would not like this feature. I like this app because is dead simple. Receive and SMS, send an HTTP request with some info. Does no more, needs no more. What I understand is requested here is quite the opposite. Expose an HTTP server that receives some info and sends an SMS with that info. A completely different story that would complicate the app. Feels like another app actually.

[jacob019]

Thank you Mr. Bogomolov for the most recent update. The configurable JSON payload really helps me. I came here to propose this feature as well. If the this app could both receive and send SMS, then it could turn a phone into a complete SMS gateway. I use a commercial SMS provider, telnyx, with my own SMS <---> XMPP bridge for my main number, problem is I cannot use it for 2FA since many companies reject VOIP numbers for 2FA, so I have another number with a cheap plan, old phone, and this app that forwards SMS --> XMPP. It works great, and I am grateful, but it would be nice to have a full bridge. I know it's probably out of scope for your project, that's ok, thanks again for this software.

[poVoq]

There used to be a similar app that could send: https://github.com/ushahidi/SMSSync

But it has been unmaintained for a while now.

I think instead of opening a http endpoint, it was regularly polling a remote location for messages to send. This causes a slight sending delay and could cause issues with Androids that go into deep sleep, but it would be much easier to setup.

[xxxserxxx]

RestSMS does this. It has problems, though; the number format is hard-coded to be international, which doesn't work at all for US-to-US numbers; it doesn't stay running very well; and it's a pain to configure, since phone IPs tend to change more frequently than desktop addresses.

I'd like to have RestSMS's functionality built into SMS Forwarder, and add a call-back set-up hook. Ideally, it'd work like this:

• SMSes can be delivered via authenticated web call, a-la RestSMS
• Like RestSMS, and auth token would be configured in the app, and would never be communicated to clients
• When the Forwarder service is started, it would attempt an initial call to the configured receiver and include the ip:port information for sending SMS.
• When an SMS is delivered, the response can contain a request for the delivery connection information. In this case, the Forwarder would make the same call as in the previous point, and send the ip:port for sending messages.

These last two provide the listener with the ability to update or register that the service is available. An alternative is broadcasting capability on UPnP, which seems like far more work.

The goal, for me, is to have a desktop chat app that uses the phone's SMS capability. I have, in fact, already written an alpha-quality TUI to do so; however, it's a PITA for users to use because it requires a lot of fussing on the phone: installing and configuring two apps, and having to restart whenever the phone IP changes in order to locate RestSMS. And, given that RestSMS is effectively broken in the US, it's mostly useless except as an interface for viewing received SMSes.

Adding RestSMS' functionality to SMS Forwarder would make it an ideal partner app for other tools for desktop integration, and make it far easier for users to set up.

Alternatives are:

• sending the ip:port in every SMS delivery. This might be the easiest implementation, at the cost of increasing payload size. Since I assume we're not using this for bulk message delivery, the overhead may be acceptable
• the current edifice: using Forwarder alongside another app like ResrSMS. I've explained why this is undesirable.
• using something like KDE Connect. The problem with this is that it works only for desktops running KDE. The mconnect project does exist, but it's poorly maintained and written in Vala, and current versions are buggy, don't maintain connections, and constantly (frequently) send re-pair requests that require user interaction.

Here's a not-very-exciting screen shot; since sending is broken, I'm adding message persisting next, since all conversation history is currently lost when the program exits.

As a postfix, I am in favor of separation of concerns; for mobile apps, though, it's often a better user experience to combine functionality, and especially in the use case I'm considering where Forwarder is partnered with a desktop app. I think adding sending isn't then feature creep, but feature completion.

[poVoq]

Why wouldn't US numbers with the international prefix work? That is just standard telephony and works everywhere else within a country or not.

But an app that can only send and not receive isn't very convenient either, especially when it depends on Android's broken network stack to serve a webhook endpoint itself.

P.s. if you are US based you should probably look into jmp.chat

[xxxserxxx]

Why wouldn't US numbers with the international prefix work?

It was a red herring; I wasn't properly URL encoding the query, and the app was rejecting the number. It's working now. The TUI is still pretty basic, but it does work as a chat client if both SMS Forward and RestSMS are running on the phone. It's just really fussy for users to set up because of all the moving parts.

Regardless, the rest of my argument remains: having both send and receive in a single app would bee a better user experience for building partner desktop apps, and having the mobile app endpoint be discoverable would be a dramatic improvement. Piggybacking on the app-to-endpoint to announce this callback information would be convenient.