search

moezbhatti / qksms

The most beautiful SMS messenger for Android
https://qklabs.com/download
GNU General Public License v3.0
4.42k stars 1.06k forks source link

Desktop messaging #818

Open moezbhatti opened 6 years ago

moezbhatti commented 6 years ago

This will be a very large undertaking - have support for sending messages via a web browser, similar to how it's implemented in Whatsapp

Raeitus commented 6 years ago

I don't know if we really need this... Whatsapp is an internet-based messenger, whereas QKSMS is a SMS-based messenger. The internet-based messenger uses a server to hold all of the info. To be able to send an SMS via web browser, you'd need to be able to mirror data between the phone & the browser.

rho333 commented 6 years ago

I think it's actually a killer feature that very few SMS apps have, but which is extremely useful. Pulse SMS does this, as does Apple's SMS solution on iOS. Being able to receive and reply to messages from any device is awesome...

Pushover Pushbullet offers end-to-end encrypted conversation sync as part of their premium package - looking briefly at their API, it looks like something QKSMS could potentially hook into. Just my $0.02...

Raeitus commented 6 years ago

We would have to host and maintain a server for this though... even Signal doesn't have this implemented into their app (for SMS/MMS).

moezbhatti commented 6 years ago

Whatsapp doesn't actually store the data on a server. They don't store anything themselves, it's all stored on your phone.

When you connect via Whatsapp Web, your phone acts as a server that the website can communicate with. It loads the messages from your phone and tells your phone to send the messages.

Google Allo works similarly

rho333 commented 6 years ago

Yeah... The most difficult part would be implementing some sort of connection broker to get the two talking. In my mind there are two main approaches:

  1. Talk directly over IP.
  2. Talk through some sort of relay service (a la Pushbullet or another messaging infrastructure).

For 1, you'd need to obtain some sort of shared token to get each others' IPs from the broker service. For 2, you'd need slightly more logic but it definitely would be doable. The main advantage of 2 is that it'd work around most of the inevitable NAT/firewall issues that some users would experience.

J-Reis commented 6 years ago

Maybe I'm missing something (this sort of thing is beyond my area of expertise, for sure), but perhaps this would be better solved via compatibility with Pushbullet, Yappy or MightySMS? No need to maintain your own service that way.

rho333 commented 6 years ago

@J-Reis AFAIK it's already compatible with Pushbullet's message sync service. It certainly seems to work for me. However, those services usually aren't open source, nor do they let QKSMS deliver a particular user experience. Fwiw, Pushbullet's SMS forwarding is ok, but definitely not great.

If you look at something like Pulse SMS' setup, it uses Google Firebase for messaging, so users would still probably have a pay a small fee to unlock the functionality (to cover the backend costs).

Or, we could go the route of a P2P system of some description, with a web server hosted on the phone.

TowelBin commented 4 years ago

there seem to be a lot of unsolved questions about the backend. I think that the best way to work this out would be to have the phone act as a web server that the computer to connect to. The biggest problem with this would be that I'm not sure if connecting through a single ip when it is on data. It would also be nice if it could work on other messaging apps, like a companion app and on ios, but these would require a lot of work since the app is mostly java and is currently just a messaging app. Maybe we should just create a new app to work on both ios and android as a companion app to any messaging app and just bundle it with qksms.

Saghen commented 4 years ago

I'm a desktop/web developer so I'm willing to assist in this. @moezbhatti may remember me from the emails we exchanged regarding background colouring. I've taken a look at how we might connect the phone and computer and I believe that DNS-SD with a fallback to network scanning would be the best option.

The computer would register itself using a DNS SRV and DNS TXT record. The phone would query the DNS PTR record for the name of the service. Using the TXT record, we can store info about the server-specific information, something along the lines of a fingerprint.

When connecting, the phone would send a request to the server with an Authorization header providing a JWT that was exchanged during their pairing process. The server would open a socket if the JWT is valid according to the computer's randomly generated secret and a socket would be formed for communication between the two devices.

This is just an idea of how this could be accomplished and I have never implemented a system like this myself but conceptually it should work and I'm willing to help implement it on the desktop side. Of course, if the DNS-SD method fails, we can resort to network scanning to search through all the IPs on a network.

sm4rk0 commented 4 years ago

Maybe use QR-code scanning to pair, like meshenger?

moezbhatti commented 4 years ago

@Saghen really appreciate the willingness to help here! I'd be happy to help with the android side of things to build a prototype for this when you have some time

By the way, just saw that you're from Burlington. I grew up in Oakville - small world

jtagcat commented 4 years ago

I'd add, that Google's Android default SMS app supports doing it via web.

QR code pairing seems to be the best solution. Android SMS uses it, whatsapp uses it.

This will probably come with QKSMS+, a hosted service? Or self-configurable self-hosted webserver container?

I'd first build the api part of it, then build the web app on top of it. This way you will easily/automatically have an API you could tie with automation services/BRIDGES. Having a bridge with Matrix.org would be preferred by me.

raphj commented 4 years ago

I am very interested in this feature, and I am currently using KDEConnect to send messages from the computer. The GNOME version has a messaging app for that, and the KDE version is getting one. These work with any SMS app.

How about using KDEConnect as a base for this work?

Saghen commented 4 years ago

I'd add, that Google's Android default SMS app supports doing it via web.

QR code pairing seems to be the best solution. Android SMS uses it, whatsapp uses it.

This will probably come with QKSMS+, a hosted service? Or self-configurable self-hosted webserver container?

I'd first build the api part of it, then build the web app on top of it. This way you will easily/automatically have an API you could tie with automation services/BRIDGES. Having a bridge with Matrix.org would be preferred by me.

The problem with QR scanning was mentioned in your comment. Moez would have to pay for web hosting which isn't that optimal. Self hosted would be too complicated for the average user imo even with a docker container.

Raeitus commented 4 years ago

How about using KDEConnect as a base for this work?

Idk how well using KDEConnect as a base would work since that wouldn't work on Windows or macOS too. It'd be best to make something cross platform.

The problem with QR scanning was mentioned in your comment. Moez would have to pay for web hosting which isn't that optimal. Self hosted would be too complicated for the average user imo even with a docker container.

Unless you can make a mini GUI program for Windows, macOS, Linux that only works over local network and have it generate a QR code that contains a key so that it can ssh to the phone or whatnot.

raphj commented 4 years ago

How about using KDEConnect as a base for this work?

Idk how well using KDEConnect as a base would work since that wouldn't work on Windows or macOS too. It'd be best to make something cross platform.

Still experimental, but KDE Connect seems to build and run on Windows and macOS.

Anyway, as a user of both QKSMS and KDEConnect, I wanted to make sure people working on this are aware of KDEConnect, even if they decide not to base their work on it. It provides a convenient pairing system between phones and computers, tools to handle texts and has integration with common browsers :-)

peylight commented 4 years ago

There are many problems with KDE Connect.

  1. You haven't your contact list.
  2. You can't receive messages.
  3. It's just a simple app to send a text to a number or see just a notify. So i think it is better to make it by QKSMS. And for many reasons make it on local network.
raphj commented 4 years ago
  1. You have (with GSConnect on Gnome and soon with KDEConnect on KDE)
  2. You can (I do (on KDE)! :-))
  3. No

See:

That does not mean KDE Connect is a good fit for QKSMS though (I would not know).

(edit to answer next comment: @peylight - are you interested in a constructive discussion or are you here to spread your hatred?)

peylight commented 4 years ago
  1. GSConnect is not KDEConnect and it is only for Gnome Desktop.
  2. Gnome is a Stupid Desktop and i never use it.
  3. Forgot it...
CrazyHoodlem commented 3 years ago

Would a WebSocket API be easy to implement for QKSMS? Sorry, I am a NodeJS and C# developer, I have pretty much 0 experience making android apps. If someone could make an API, I'd love to make a desktop/browser client for it.

Two options of implementation:

jtagcat commented 3 years ago

Flexibility wise, having the QKSMS mobile app talk to a (microservice) server sounds the sanest.

If you self-host, or pay to have it hosted by the devs, you point the app to that server. If you don't want to, you have the flexibility to integrate, and host the server on your phone (down the line).

The desktop messaging thing would only be a relay, the server as an idea of course is on the phone (central conflict resolver, source of truth, what actually holds the data, what sends/receives SMS). If you'd make the server on the desktop / cloud, you couldn't send SMS from your phone when (AWS/Google/name some more) is down. Additionally, this shouldn't be a rearchitecture of the whole app, rather an integration, an addition.

I'd say you need to ask with more context. If you'd have just an API on the phone, you'd need something to access it. On the networking side you have firewalls, NATs and other (future) things you have to deal with. You probably don't want to deal want to deal with the relaying and things related to that.

(For LAN-only connections,) I'd look for QKSMS integration (plugin!) with KDE Connect on both the mobile side, and the desktop, as they have networking, distribution, setup, etc in place.

Raeitus commented 3 years ago

IMO, the easiest way to do this is probably host the server on the phone, so that you can use any web browser on desktop to send SMS/MMS. So that we don't have to worry about creating a desktop app.

You need to make sure the connection is secure and encrypted.

vincent1890 commented 3 years ago

+9999999.... for QKsms on Web Browser

CrazyHoodlem commented 3 years ago

@trymeouteh most likely it would use a local server and not a remote server. I don't think P2P over LAN is any better than any other type of local connection.

NovaViper commented 3 years ago

There could be something similar to Plex, a local server on a computer and a UPNP protocol that broadcasts the server publicly.

jtagcat commented 3 years ago

(your reminder to stop +1 +9, whatever, and saying things already said, it pings more than a dozen persons)

TowelBin commented 3 years ago

I think we would need some kind of a minimal central server, acting as a sort of catalyst connecting the phone and website with minimal work being done on the central server and acting as an interface for the web version. Regardless, This solution would cost some money. Domains seem to be very cheap (unless there is some hidden cost), so the expense would be in hosting.

peylight commented 3 years ago

It is possible to use Ktor framework to running an HTTP server on an Android app

blueforesticarus commented 3 years ago

I think a matrix bridge would be the way to go here. Then you don't need to make a client, there are already many clients.

blueforesticarus commented 3 years ago

It could be set up so that qksms can be a headless matrix client. It would be authenticated to your matrix account the same way a normal matrix client is. Then when you send or receive a text message in qksms, it would synchronize the graph in with matrix (under the hood matrix is a graph synchronization protocol). Likewise if you send a text from through a matrix client, qksms would receive it and could send the message.

niks255 commented 2 years ago

I think a matrix bridge would be the way to go here. Then you don't need to make a client, there are already many clients.

But matrix bridge would require a matrix server you can trust and an internet connection. Besides, such a bridge already exists https://github.com/tijder/SmsMatrix I like the approach with the local web server much more. But that's just my opinion.

AkechiShiro commented 2 months ago

I'm very much interested in this feature, is there anyone willing to help me make a PR or a fork of QKSMS with this feature ?