Propose the application on F-Droid

[mdeweerd]

Proposing the application on F-Droid would help streamline the installation, and notifications about updates, and increase visibility of the project.

sms gateway webhook is a similar but simpler projet that is proposes on F-Droid.

[capcom6]

Hello!

Thank you for your proposal.

Unfortunately, the current version of the app heavily depends on Firebase Cloud Messaging (FCM), which is part of Google Play Services. Since Google Play Services is proprietary software, it violates F-Droid's rules. As a result, the app cannot be published on F-Droid in its current form.

I have plans to implement an alternative to FCM, but there is no timeline for this at the moment. It's worth noting that any alternative will likely be less efficient than FCM, particularly in terms of battery life.

I'll keep this suggestion in mind for future development.

[pepper3k]

1. What's the justification for depending on FCM?
2. Can it be replaced by something like UnifiedPush (my assumption is that it could) ?

[capcom6]

Hello, @pepper3k

1. The justification is straightforward: it was the simplest solution for the first version of the app. FCM doesn't require any external dependencies and is supported by a vast number of devices. Additionally, it doesn't require any additional actions from the user.

2. Thank you for mentioning UnifiedPush. While it could potentially replace FCM, UnifiedPush requires installing an additional app on the device - the distributor. I believe that depending on a third-party app is not the best approach.

[kuba-orlik]

I think it would be nice to have the f-droid version published with certain features removed (the ones that require FCM). It would be better than to not have the app in FDroid at all

[hasan-4]

1. What's the justification for depending on FCM?
2. Can it be replaced by something like UnifiedPush (my assumption is that it could) ?

what about using WebSocket ? we can implement online status feature for android sms gateway. and pulling sms every 15m will not be necessary in this model.
i'll be happy to collaborate on creating the backend using nodejs, socket.io, postgresql | mariadb | mysql

[hasan-4]

we can also add rest api feature with websocket those who prefer it

[capcom6]

@hasan-4

You're not the first to ask about WebSocket support. This feature is already on my backlog, though it's not currently a top priority.

The main challenge with any always-online solution is power consumption and Android's battery optimization features, which may terminate the app at any time. The WebSocket support would be implemented as an optional feature. The FCM version will remain available.

Regarding message pulling every 15 minutes: the app already includes a Ping feature that allows you to pull messages at custom intervals while also sending a system:ping webhook to your server for online status monitoring. You can enable this in the app settings: https://docs.sms-gate.app/getting-started/public-cloud-server/#__tabbed_1_3

Thank you for your collaboration offer! However, the backend is already written in Go.

Regarding your REST API comment - could you clarify what you mean? The app already uses REST API for communication.

[hasan-4]

yes. current backend offers rest api.

i just wanted to say backend will offer 2 flavor to developer in previous message:

1. websocket
2. rest api

thanks.

[capcom6]

@hasan-4 ,

Are you referring to implementing a user-facing WebSocket API?

In our previous discussion, WebSocket was primarily considered for device-server communication as an alternative to FCM. A user-facing WebSocket implementation would complicate the architecture without providing substantial benefits, while also introducing compatibility issues between the device and server public APIs.

Regarding device status monitoring:

• In Local Server mode, each connection attempt already provides device status information, making WebSocket unnecessary for this purpose.
• In Cloud mode, WebSocket wouldn't be effective for receiving events like sms:received since these are sent directly from the device, and the server wouldn't be aware of them.

I'm currently not convinced about the value of implementing a user-facing WebSocket. However, you can easily convert webhook events to WebSocket on your application side, as demonstrated in our example web client: https://github.com/android-sms-gateway/web-client-ts

[hasan-4]

thanks