quik
quik copied to clipboard
octoshrimpy
✏️ [ FEAT REQ ] Web API for LAN SMS - non-RCS, no client install
Is your feature request related to a problem? If so, please describe the problem. Not really a "problem", but lack of really important functionality - a web messaging allows to "copy" data from/into SMS which is very convenient, also typing SMS with PC keyboard is way more effective. Would be nice to have something what Google provides.
Describe the feature you'd like Exact behavioral copy of google web messages. A messaging app in JS possibly that connects to the phone via WiFi or LAN (best scenario, if that is harder to achieve, may be any network, but I suppose it would be even nice to specify the local/lan phone IP if possible or something, anything will do, just let it happen :D )
Additional context You know where to find google web messages. https://messages.google.com/web/authentication
If this will be only a stub that uses LAN then there will be no problem with hosting, privacy and so on.
PS. I will be happy to become a tester (im also a dev, so it may help)
dupe of #9, but with more info. copying this to the other one and closing this as dupe.
I'm sorry to disagree, but #9 is not even close, the simple proof is that in the first comment you already proposed a database syncing (which would probably be ok for a desktop app), but here is rather overhead.
Pleas do not mix topics. Web app is a web app, it can be used on the phone, on tablet, on raspberry pi, on anything. Desktop app is system-binded (ie. windows exe or linux elf) and is completely different story
By the way, web app does not need to be even written by you, you just need to provide an API.
How on earth did you end up with such thought? What does web application have in common with system_dependent kdeconnect software that has to be installed, maintained over different systems, is written for specific framework (KDE, name explains) and also is written in C++?
Do we speak the same language?
@KaJakKrzysztof, do you want to build it, or are you going to continue to belittle me and the work so many volunteers have put towards keeping this app alive?
It's not about you and I'm sorry if you took that personally. I just want to be well understood, and the first thing that happened was to merge my feature request with something that is not what I asked for, then other ideas still not even close, that's why I asked for reconsideration.
Again, yes, if you make an API which will be a "window into received SMS list" and also API (separate or merged) for sending SMS, we will of course make some apps for you (we, I mean, I am C++ dev, so I can make something system-based, but someone much more knowledgeable than me in JavaScript web apps should do the thing I ask for). I suppose there will be even more people eager to do that, as there is no competition to Google Web Messaging at all.
Also, if this would be API accessible by any means (like local network, ie. providing IP:PORT/user:pass for the web application that will connect to the phone you like) then it would change completely the way people use it (right now there is only google.internet.web.portal that needs to be connected to your phone, which is by definition WRONG because whoever owns that site, has access to you messages also :P). For example, it could be even used from unix scripts to connect to your phone and send some SMS, or better - your phone could connect to the unix box and allow it to send messages (this way you do not need to care about ip:port of the phone because the phone would initiate connection, so only QUIK could know the ip:port/user:pass of the unix box and provide the API to that box). This would allow to communicate perfectly. If you want, try to look at gotify - this is the self-hosted messaging that can allow you to imagine how the things can be done (of course, your API does not have to be as complicated as that, just connect & serve some messages in json, easy-peasy)
If you care about QUIK, I suggest to "unduplicate" this FEAT REQ and reopen it as it will really bump up the usablility of QUIK VERY MUCH (I and most of the people I know abandoned QKSMS, TEXTRA and others because of lack of receiving SMS on the PC via web browser which Google Messages allows, so we all fall back to Google unfortunately)
lack of really important functionality
This isn't something "really important" for an SMS app. Apps, by default, are meant to be standalone applications on your mobile phone.
Would be nice to have something what Google provides
Agreed. having the server capacity and storage/ram headroom they do would be fantastic.
A messaging app in JS possibly that connects to the phone via WiFi or LAN (best scenario, if that is harder to achieve, may be any network, but I suppose it would be even nice to specify the local/lan phone IP if possible or something, anything will do, just let it happen :D )
Friend, KDEconnect connects to your phone via WiFi through your LAN, with optional settings built-in for VPNs, has a solid browser extension, music control, media pause on all connected devices when phone rings, remote pointer, completely customizable commands and more.
You know where to find google web messages
I actually didn't until you posted that link. I do not use google messages, and avoid google products where I can. I can always look it up, for sure, and I do understand the concept, as I use kdeconnect to send sms from my various PCs.
If this will be only a stub that uses LAN then there will be no problem with hosting, privacy and so on.
see kdeconnect above
I'm sorry to disagree, but https://github.com/octoshrimpy/quik/issues/9 is not even close,
That's fine, you can disagree if you'd like. You are a free human being that is able to think on your own, and should be allowed to do so.
Web app is a web app, it can be used on the phone, on tablet, on raspberry pi, on anything. Desktop app is system-binded (ie. windows exe or linux elf) and is completely different story
https://v2.tauri.app https://www.electronjs.org https://reactnative.dev https://bitbucket.org/chromiumembedded/cef/src/master/ https://wails.io https://github.com/Textualize/textual-web https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor
...and I could go on.
How on earth did you end up with such thought? What does web application have in common with system_dependent kdeconnect software
see answers above
has to be installed, maintained over different systems, is written for specific framework (KDE, name explains) and also is written in C++?
- kdeconnect exists for everything, even sailfishOS, but it's starting to sound a little bit like you didn't even check, but that's just a gut feeling on my part.
- what does C++ have to do with anything? and before you say "it doesn't run on browser!", it's not even that difficult to throw into WASM, let alone find step-by-step guides for it, but I digress.
Do we speak the same language?
as of right now, I don't know, to be quite honest.
It's not about you and I'm sorry if you took that personally
https://en.wikipedia.org/wiki/Non-apology_apology
[...] <large paragraph>
Thank you for the request specs. With these we can start working towards finding solutions.
lack of really important functionality This isn't something "really important" for an SMS app. Apps, by default, are meant to be standalone applications on your mobile phone.
If that is not important, why do you use it via third party app like kde connect? You contradict yourself. Also, google does not produce anything that is not needed, their web messaging is very widely used, and as I said, a lack of web messaging is a reason of dropping message apps non-google.
Would be nice to have something what Google provides Agreed. having the server capacity and storage/ram headroom they do would be fantastic.
You are trying to be sarcastic, but sarcasm needs to be at least "smart". This isn't.
A messaging app in JS possibly that connects to the phone via WiFi or LAN (best scenario, if that is harder to achieve, may be any network, but I suppose it would be even nice to specify the local/lan phone IP if possible or something, anything will do, just let it happen :D ) Friend, KDEconnect connects to your phone via WiFi through your LAN, with [optional settings built-in for VPNs (https://userbase.kde.org/KDEConnect#Running_KDE_Connect_over_OpenVPN), has a solid browser extension, music control, media pause on all connected devices when phone rings, remote pointer, completely customizable commands and more.
kde connect is:
- unstable
- needs to be installed (so you need to have admin rights)
- stays there (so if you try to message via company PC it's not what you want)
- has many unnecessary functions
- is constantly connected instead just when you use "messaging"
and more.
But as I see, explaining anything is pointless here since you do not listen so I'll pass mentioning more unless you will have a will for real discussion
You know where to find google web messages I actually didn't until you posted that link. I do not use google messages, and avoid google products where I can. I can always look it up, for sure, and I do understand the concept, as I use kdeconnect to send sms from my various PCs.
A pity that "an android sms app expert" does not know what's available world-wide for everyone by the most known android company :P (now that's sarcasm :P)
If this will be only a stub that uses LAN then there will be no problem with hosting, privacy and so on. see kdeconnect above
As I said above, kde connect has more flaws than features, also it's a binary, not a non-system-related, run-on-the-fly (not installable), lightweight web-script
I'm sorry to disagree, but #9 is not even close, That's fine, you can disagree if you'd like. You are a free human being that is able to think on your own, and should be allowed to do so.
Please, if you do something, try to do it the best it can be. Sarcasm is not you area of expertise for sure.
Web app is a web app, it can be used on the phone, on tablet, on raspberry pi, on anything. Desktop app is system-binded (ie. windows exe or linux elf) and is completely different story https://v2.tauri.app https://www.electronjs.org https://reactnative.dev https://bitbucket.org/chromiumembedded/cef/src/master/ https://wails.io https://github.com/Textualize/textual-web https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor
...and I could go on.
Please do, it is quite off-topic, so I plainly ignore this.
How on earth did you end up with such thought? What does web application have in common with system_dependent kdeconnect software see answers above
see answers above, you still do not get the point. Web app. A script. No binary. Miltiplatform. Universal. Not installable. Stable on any platform. Once done, works everywhere.
has to be installed, maintained over different systems, is written for specific framework (KDE, name explains) and also is written in C++?
- kdeconnect exists for everything, even sailfishOS, but it's starting to sound a little bit like you didn't even check, but that's just a gut feeling on my part. As i said, unstable. Also you need to install it on every hardware you have, so most of the time you need admin and you use space, and kde connect provides 90% of not connected to his topic features which also pose security risk (ie. remote control)
- what does C++ have to do with anything? and before you say "it doesn't run on browser!", it's not even that difficult to throw into WASM, let alone find step-by-step guides for it, but I digress.>
Compilation/installation. I said C++ just as an most usual example of compiled, platform specific, system specific even, binary.
Do we speak the same language? as of right now, I don't know, to be quite honest. No we don't. Or maybe we speak, but you don't listen.
It's not about you and I'm sorry if you took that personally https://en.wikipedia.org/wiki/Non-apology_apology
You are mistaken. I apologised YOU for how you FEEL. I did not want you to FEEL anything, I just wanted to encourage you to analyse what I wrote. So I apologised about THE WAY I expressed my thoughts. If you do not understand that, I'm sorry again, but can't do anything more about it.
[...]
Thank you for the request specs. With these we can start working towards finding solutions.
I assume this is another failed sarcasm because it doesn't belong anywhere (to sarcasm either).
If I may interject, Here are some of my thoughts regarding this:
- I personally think that what I proposed earlier using Compose Multi Platform to create it is still the best option. However, I'm willing to be wrong.
- Having an API that another program could access, as you suggested, is a good idea, however, I believe it would require adding a separate app module. I believe that this would be best, that way QUIK remains with no internet permission. In addition, some may not want even the option of having an API. I am one of them.
- Having an API could involve using the backup mechanism to access the database (in JSON). Then you could have the other web messaging program call the API for the Conversations list, and then all the messages in each conversation, that way the entire database is not shared, at start up, which, in some use cases, could be impractical because of size.
- Building the Web Messaging application might be done by working off of another Web Messaging Platform. This is a large endeavour. And yes, someone else could offer to do it. But the chances of that happening are very low.
- Other things to consider include authentication and making sure the API is encrypted.
- We also would have to consider would we want the API to work only over Wi-Fi or also over Bluetooth.
- My point in all this is that an API while helpful is still a massive amount of work, especially with making sure that the security is right.
- As I said, I believe that rewriting the app in Compose multi-platform and then adding a module which allows accessing the database through some means, maybe the one I just suggested, is the best option and that would give us web support eventually.
- Please let's not get upset with one another, we are all a bunch of unpaid volunteers working here.
Regarding "really important functionality", I believe that other proposed features should take precedence such as end to end encryption or RCS. I personally would benefit immensely if desjtop/web was implemented, but I think other enhancements should take precedence.
In addition, regarding this being related to #9, it is because it will involve the same code changes. With both desktop and web, it is required to get the database accessed some way remotely, somehow, an application will have to be built, preferably in some cross-platform language, so we do less work. I agree that to the end user, it's not that related, but to the people implementing this feature they are completely intertwined.
Regarding "really important functionality", I believe that other proposed features should take precedence such as end to end encryption or RCS. I personally would benefit immensely if desjtop/web was implemented, but I think other enhancements should take precedence.
If the RCS will be implemented at all, then yes, it's more important for sure. But will it be implemented? Also, RCS is not yet used in my country for example, so this is exclusive content, not for the whole globe.
In addition, regarding this being related to #9, it is because it will involve the same code changes. With both desktop and web, it is required to get the database accessed some way remotely, somehow, an application will have to be built, preferably in some cross-platform language, so we do less work. I agree that to the end user, it's not that related, but to the people implementing this feature they are completely intertwined.
Agree, but I meant that:
- This is about web app, portable, not system-dependent one and was appended to wrong topic
- Topic about accessing messages db which is below QUIK shoudl be completely separat topic named "Messages API"
- There should be subtopics of "Messages API" specifying "intent api" (ie. tasker), "network api" (any web/and/or/system_dependent app), and others if needed
So basically, what I have proposed was "client" that uses "API". And how that API should look, I never even discussed that (only suggested that web app idea is lightweght and secure because it can even use local network api), but that was just an idea for you to design it the right way (whatever you choose).
If I may interject, Here are some of my thoughts regarding this:
sure, you are welcome to be honest
- I personally think that what I proposed earlier using Compose Multi Platform to create it is still the best option. However, I'm willing to be wrong.
To be honest, however it will be done, not my few cents. I just suggest doing it. And my only VERY important suggestion is for it to be a WEB (JS based) APP. That's a must for me - portability, lightweight and completely "ghost usage" (no traces it was ever used when browser cache is cleared)
- Having an API that another program could access, as you suggested, is a good idea, however, I believe it would require adding a separate app module. I believe that this would be best, that way QUIK remains with no internet permission. In addition, some may not want even the option of having an API. I am one of them.
Good idea. So as I above mentioned, intent API first, then separate "plugin" which will have internet rights to serve via LAN/WAN
- Having an API could involve using the backup mechanism to access the database (in JSON). Then you could have the other web messaging program call the API for the Conversations list, and then all the messages in each conversation, that way the entire database is not shared, at start up, which, in some use cases, could be impractical because of size.
Yes. Sync should be separate process. At start and on-demand-only if something causes desync. Normal access after sync should be simply via API events.
- Building the Web Messaging application might be done by working off of another Web Messaging Platform. This is a large endeavour. And yes, someone else could offer to do it. But the chances of that happening are very low.
I suppose this is very simple endaevour. Building just a GUI for an existing API is quite easy. But i'm not an expert here.
- Other things to consider include authentication and making sure the API is encrypted.
That's something that can be done as a last thing when API already exists. As a last resort you can simply use SSL as encryption and any authentication mechanism below.
- We also would have to consider would we want the API to work only over Wi-Fi or also over Bluetooth.
BT is not necessary. It has very short range and is usually not available for "normal" software (ie. I did not even see any web bt based apps, despite it is possible to write ones afaik, but im not sure). This is something that can be done later if you have time.
- My point in all this is that an API while helpful is still a massive amount of work, especially with making sure that the security is right.
Hmmm. Disagreed. That's I do daily as a backend dev. API's in JSON are easy. Security = use ready for use libs, don't do it yourself.
- As I said, I believe that rewriting the app in Compose multi-platform and then adding a module which allows accessing the database through some means, maybe the one I just suggested, is the best option and that would give us web support eventually.
Again, don't know, don't care what tools you will use, but be careful - the more you make dependent on something, the worse for you, also, rewriting the whole app is something as you call "massive amount of work" which is probably not necessary at all to make an API.
- Please let's not get upset with one another, we are all a bunch of unpaid volunteers working here.
Sure. I just needed real discussion instead of being redirected to /dev/null
I propose then making two more issues.
- An issue as @KaJakKrzysztof suggested for the API.
- A meta issue with links to this issue, the desktop issue and the API one. @octoshrimpy Thoughts?
My point in all this is that an API while helpful is still a massive amount of work, especially with making sure that the security is right.
Hmmm. Disagreed. That's I do daily as a backend dev. API's in JSON are easy.
I'm sure that this is easy for someone who's familiar with this. However, I am not. Regarding priority of this issue, It will get done when one of the maintainers or any other developer has the time and experience to implement it. I currently have neither, but I can't speak for everyone.
Thank you for all your points. They have given me some ideas regarding this.
@KaJakKrzysztof nothing that I said was sarcastic. We are on the same team, please refrain from trying to force this convo into a fight. @Inhishonor thank you for the rational thinking.
If we open up an API, like @Inhishonor said, this would be best suited for one of those modules i've mentioned in the past. It would need to be secure, as anyone in the network would be able to access the webpage.
Hmmm. Disagreed. That's I do daily as a backend dev. API's in JSON are easy. I'm sure that this is easy for someone who's familiar with this.
easy with a server running all the time, a phone is usually meant to be a client, not a server. We need more research into it for sure.
having an API would open up a lot more options, such as scripting against it. maybe a pubsub system would work well?
If we open up an API, like @Inhishonor said, this would be best suited for one of those modules i've mentioned in the past. It would need to be secure, as anyone in the network would be able to access the webpage.
As a starter you can use uuid generated on the client and then passed via QR code and accepted by QUIK API after user granted access. That's the simplest idea, but of course you can extend it more by password or anything.
Hmmm. Disagreed. That's I do daily as a backend dev. API's in JSON are easy. I'm sure that this is easy for someone who's familiar with this.
easy with a server running all the time, a phone is usually meant to be a client, not a server. We need more research into it for sure.
Try to do it exactly as google web messages. I suppose it is based on android framework somehow (websockets via framework?). If the framework won't help then maybe simple network programming like blocking socket? (dunno how android does it, but on linux if you open listening socket in blocking mode, the app is sleeping until socket can be read - the app as the thread of the app - in other threads you can take care of the real messages)