Multi Protocol Chat Client

Question

76

Multi Protocol Chat Client

idea

asked 2019-04-02 14:44:15 +0300

spag
1701 ●9 ●14 ●18

updated 2019-04-03 11:17:12 +0300

I have been brooding over this idea for quite a while now and I'm still not sure if it's just me that thinks having a

Multi Protocol Chat Client

supplementing the existing chat applications on Saifish would be a good idea.

After all, the very essence of any of these chat applications is to exchange chat messages, send/receive photos, arbitrary files and sometimes also voice messages or real-time voice/video streams.

I don't really see anything that would require every single protocol to have a dedicated app on SFOS. This could furthermore even free developers from having to reinvent the (UI) wheel over and over again every time a new protocol comes around.

e.g. I already have a few protocol daemons here which I mostly use from the command line:

Telegram
Threema
IMAP/SMTP
Matrix
XMPP

All it would take to make them work on SFOS would be to create a common meta-protocol to tie together the actual protocol bits and the UI part (e.g. simple JSON sent back and forth over stdin) and to wrap a nice GUI around all of this.

But before I start wasting my time developing something no one really ever asked for I would like to make sure there is some actual demand for such an extravagance.

Please leave a vote should you be interested in a Multi Protocol Chat app for SFOS.

PS: And yes, I know it's basically what Jolla have tried with Telepathy years ago but, in contrast to this, this project is meant to be a stand alone app.

edit retag flag offensive close delete

Comments

That would be awsome. Actually for those closed source apps such as Threema and WhatsApp it may be an option to integrate a runner for the Web-UI that parsed HTML-Content and presents it in such a Multi Protocol Chat Client.

jollajo ( 2019-04-02 15:14:52 +0300 )edit

2

I do have a functioning native Threema protocol implementation lying around here actually so there's no need for anything web based at least for this one.

When it comes to WhatsApp you still need to run the Android app somewhere.

spag ( 2019-04-02 15:19:23 +0300 )edit

1

i'd prefer something like that integrated in the OS.

ApB ( 2019-04-02 15:26:46 +0300 )edit

1

Sorry, but that isn't an option here as this is too limited to accommodate any modern protocol and also totally complicated to develop for. You can either wait for Jolla to make it work (which will probably never happen) or go with a dedicated client.

spag ( 2019-04-02 15:37:24 +0300 )edit

1

I would very much like such a native app. have you considered adding Signal to the list? The only native app (whisperfish) is not maintained anymore since about one month and there's no alternative!

laubblaeser ( 2019-04-02 17:13:40 +0300 )edit

That would be awsome. Actually for those closed source apps such as Threema and WhatsApp it may be an option to integrate a runner for the Web-UI that parsed HTML-Content and presents it in such a Multi Protocol Chat Client.
jollajo ( 2019-04-02 15:14:52 +0300 )edit
I do have a functioning native Threema protocol implementation lying around here actually so there's no need for anything web based at least for this one.
When it comes to WhatsApp you still need to run the Android app somewhere.
spag ( 2019-04-02 15:19:23 +0300 )edit
i'd prefer something like that integrated in the OS.
ApB ( 2019-04-02 15:26:46 +0300 )edit
Sorry, but that isn't an option here as this is too limited to accommodate any modern protocol and also totally complicated to develop for. You can either wait for Jolla to make it work (which will probably never happen) or go with a dedicated client.
spag ( 2019-04-02 15:37:24 +0300 )edit
I would very much like such a native app. have you considered adding Signal to the list? The only native app (whisperfish) is not maintained anymore since about one month and there's no alternative!
laubblaeser ( 2019-04-02 17:13:40 +0300 )edit

Answer 1

18

answered 2019-04-02 16:07:28 +0300

nthn

12631 ●154 ●230 ●225

updated 2019-04-03 19:17:52 +0300

Honestly, if you have the skills to create daemons for multiple protocols, please do look into making those daemons compatible with Telepathy (not just through libpurple but as actual Telepathy components). It benefits not just tiny little Sailfish OS, but all GNU/Linux distributions. On top of that, it would require virtually no work from Jolla's side to integrate everything into the Messages application, excluding protocol-specific oddities like sending stickers, or having a key verification page for encryption. Most things would already work fine by simply installing their telepathy-protocolxyz RPM package, and if Jolla doesn't do the necessary work to make everything integrate perfectly with the Messages (and even the Phone) application, you can still create your own UI frontend that taps into the different daemons and gives easy access to the microphone, camera, etc.

Either way, as you've already guessed, I'm all for a multi-protocol chat client.

Edit: just to prove that Telepathy is not dead:

there's a Matrix connection manager in the works: https://github.com/TelepathyIM/telepathy-tank/ (it even has an RPM spec file for Sailfish OS!)
there's a Telegram connection manager: https://github.com/TelepathyIM/telepathy-morse as well as an account settings plugin for, you guessed it, Sailfish OS: https://github.com/TelepathyIM/sailfish-settings-accounts-extensions-telegram

edit flag offensive delete publish link

Comments

As I've said before, I've looked into this for quite a while and beating a dead horse as is Telepathy is not an appealing option for me. What I have envisioned would also make it actually easy for others to contribute protocol daemons which, if we stay with a defined JSON over stdin/stdout (or anything that would work for that matter and be really, really easy to work with) would separate the UI completely from the protocol parts which in turn could be written in any supported language.

Giving the daemons access to microphone/camera would only be required for real-time audio/video if I understand it right.

spag ( 2019-04-02 16:28:40 +0300 )edit

1

Maybe OT here, but where does the dislike for Telepathy stem from and why did KDE scrap it?

Kopekenscheich ( 2019-04-02 23:21:18 +0300 )edit

2

I agree, using Telepathy would be the preferred way to realize this. Why write a new framework when there's already an existing one.

Telepathy is all open source, so one could add the missing features. Also I think if there would more contribution by the community Jolla will be more than happy to help to improve Telepathy.

scharelc ( 2019-04-03 09:36:51 +0300 )edit

Feel free to go down the rabbit hole of dealing with Telepathy but I certainly won't waste my time on this so (at least for me) it will be either a standalone app or not be implemented at all.

spag ( 2019-04-03 11:20:25 +0300 )edit

I haven't looked into Telepathy. Is it really such a mess?

scharelc ( 2019-04-03 14:37:42 +0300 )edit

Answer 2

7

answered 2019-04-03 18:02:44 +0300

spag
1701 ●9 ●14 ●18

I think I should start with building a prototype including a module for Threema first. There seems to be none for SFOS yet (except for the experimental command-line client I've created for SFOS last year) and there must be like 4 or 5 Telegram clients for Sailfish already.

edit flag offensive delete publish link

Comments

1

Sounds great. Maybe copy this answer to your initial post as an edit. It might be interesting for others to quickly see where you're heading atm.

laubblaeser ( 2019-04-03 19:56:24 +0300 )edit

we have now two nice telegram apps threema has a good ewputation, but in my case no conracts :)

pawel ( 2019-04-03 22:08:34 +0300 )edit

1

I have to admit I don't know many people that are using Threema either. It just seemed to make sense to start with a protocol that no other Sailfish app has supported yet.

spag ( 2019-04-04 15:09:29 +0300 )edit

1

Good thing. I would like a native threema-client for SFOS. It's the favorite chat app of my family ;-)

silta ( 2019-04-04 22:00:02 +0300 )edit

1

The Threema transport module already works, means you would be able to send/receive messages using a native client if you don't mind copy&pasting JSON hashes :)

 {"text_message":{"text": "Hello World", "recipient_id": "ABCDEFGH"}}

{"delivery_receipt_message":{"id":"4664240904357277592","sender_id":"ABCDEFGH","recipient_id":"XUXDWWTE","status":1}}

spag ( 2019-04-04 23:22:23 +0300 )edit

Answer 3

6

answered 2019-04-02 15:55:48 +0300

dirksche

932 ●25 ●43 ●49

updated 2019-04-02 19:09:04 +0300

Thats a great idea. I use imap, threema and xmpp

edit flag offensive delete publish link

Answer 4

5

answered 2019-04-02 15:05:27 +0300

Kopekenscheich

758 ●6 ●19 ●26

I reckon there absolutely is demand!

edit flag offensive delete publish link

Answer 5

3

answered 2019-04-02 19:17:13 +0300

as400
311 ●9 ●11 ●15

Great idea !

edit flag offensive delete publish link

Answer 6

2

answered 2019-04-06 10:54:44 +0300

mosen

9271 ●92 ●132 ●145

http://mosushi.de/

Sir, may i kindly ask where i can throw my money at you?

edit flag offensive delete publish link

Answer 7

1

answered 2019-04-03 00:37:09 +0300

r0kk3rz

10112 ●108 ●186 ●181

updated 2019-04-03 00:39:14 +0300

There is a start for a Libpurple based messaging client, which is probably the best option for the multi-protocol client anyway.

https://github.com/Michal-Szczepaniak/Morsender https://build.merproject.org/package/show/home:mister:Morsender/Morsender

edit flag offensive delete publish link

Comments

1

I know Morsender but still would prefer to have a client that actually works.

spag ( 2019-04-03 00:43:23 +0300 )edit

There is also nothing that could prevent someone from adding any possible protocol modules (also based on libpurple if someone so wishes)

spag ( 2019-04-03 00:47:08 +0300 )edit

@spag if you want to make your own thing, then go do it! you don't need anyones permission

r0kk3rz ( 2019-04-03 01:14:47 +0300 )edit

If there was a client I could use I would not have to think about starting one :)

spag ( 2019-04-03 01:38:39 +0300 )edit

Actually, your idea is easy to extend when it comes to protocols, if you find a library in what ever programming language, you can run it with a subprocess. If the UI understand a bit of JSON, like you said, QML can directly use it. You have to write a translator layer between the subprocess and the UI, but that should be all.

Dylan Van Assche ( 2019-04-03 08:59:24 +0300 )edit

Answer 8

1

answered 2019-04-09 21:20:18 +0300

laubblaeser
409 ●12 ●19 ●24

Do you have a rough idea of the time needed until certain milestones in the development of the multi protocol client? I'm asking because I face more and more problems with whisperfish (native Signal client) and would be interested to hear a bit more about your plans / timeline for this project.

When are you planning to start the development? Do you already have a rough timeframe for the project?
Do you have someone else supporting you with the coding or would you rather code the first iteration on your own?
Which protocols are you planning to implement in the short term? You've mentioned in another post that you'll start with Threema - any other plans or will you rely on other people to implement other protocols?
Do you need any help with graphics, UI design or similar things? There are lots of creative people around here - don't hesitate to ask.
Can we support you in any way? Device donations? Money donations? Cookie donations? I'd be willing to bet that the SFOS community is open to provide some support for your endeavour. Don't be too shy to ask! :)

edit flag offensive delete publish link

Comments

1

It's a none man show at the moment and it's pretty hard to estimate how long it could possibly take to develop something I could dare to release to the public.

It's not my first chat app, though, so I do have a rough idea what it takes to build this one but still can't predict how much free time I will have, sorry.

It's quite a niche application and I don't expect the rather tiny Sailfish community to be able to help me much at this point. Should I be able to present something that actually works this could change of course.

I've started with Threema because there were zero Threema apps on SFOS and it made sense to me to start with this protocol. Once this works reasonably well I've planned to do 1-2 reference implementations for other protocols but haven't decided on which ones yet. I do use Telegram so this would be the obvious one but there are like 4 other Telegram clients around so it could probably also wait a little longer.

Unfortunately I'm not that familiar with Signal and haven't looked at the sources of Whisperfish yet - if it's easy to extract/access the underlying library then it could be entirely possible I implement Signal as well.

Right now I do have a working prototype that can send/receive Threema messages:

spag ( 2019-04-09 21:48:32 +0300 )edit

Answer 9

0

answered 2019-04-02 22:45:53 +0300

pawel

14895 ●231 ●341 ●376

updated 2019-04-02 23:14:23 +0300

Great Idea ! Have you considered Delta Chat?

https://delta.chat/en/

edit flag offensive delete publish link

Comments

My idea was to create the GUI as well as a few reference implementations of chat protocol modules and then everyone is free to add any new protocol as they like.

spag ( 2019-04-02 22:52:36 +0300 )edit

Delta Chat is basically just encrypted email. I've done some tests with DC for Android a few months ago when I've been researching protocols for this project. I have been able to receive the chat messages but I never made the attempt to decrypt them.

spag ( 2019-04-02 23:34:39 +0300 )edit

pretty cool.idea and easier then to convince people to use another chat client in addition to whtsapp

pawel ( 2019-04-03 22:04:14 +0300 )edit

Answer 10

0

answered 2019-04-05 23:49:27 +0300

paolomi
581 ●5 ●12 ●16

It's not easy at all to make a multi-protocol client work well nowadays. I think it's a good idea to first make separate clients that do one thing but do it great. In fact the problem with multiprotocol clients is that they often don't support any of the protocols fully, but only add more and more.

Good luck :-)

edit flag offensive delete publish link

Comments

4

The idea behind this project is precisely to turn this premise on its head!

The very essence of this project is meant to be an extremely easy to develop for, modular approach with protocol modules that can be developed by different individuals or groups who won't be forced to create a GUI, message storage, etc. over and over again. Especially for something that (from the user's perspective) is 99% the same thing, no matter which protocol you're using underneath: exchanging text, pictures, audio, etc.

spag ( 2019-04-06 00:00:59 +0300 )edit

1

Personally I maybe need 2 or 3 different protocols so this will probably end up as the reference implementations and I don't see the threat of spreading my focus into too many protocols. But everyone is free to add new ones with different degrees of support so there will, of course, be some that have a nearly full set of features and others that just offer basic functionality - but I don't see how this should be different with multiple, individual apps.

spag ( 2019-04-06 00:15:37 +0300 )edit

1

it sounds like you want to reinvent libpurple but with a client / server model

r0kk3rz ( 2019-04-08 02:18:16 +0300 )edit

Multi Protocol Chat Client

Comments

10 Answers

Comments

Comments

Comments

Comments

Comments

Comments

Question tools

Stats

Related questions

Multi Protocol Chat Client

Comments

10 Answers

Comments

Comments

Comments

Comments

Comments

Comments

Question tools

Public thread

Stats

Related questions