search

kontalk / androidclient

Kontalk official Android client
https://www.kontalk.org
GNU General Public License v3.0
571 stars 194 forks source link

Share history among clients #250

Open jluttine opened 9 years ago

jluttine commented 9 years ago

It seems that Kontalk does not share messages between clients if I use multiple clients for the same acount. Is it possible to fix this? If I use several clients, I'd like to see the whole discussion history in each client, and receive all messages to all clients.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

daniele-athome commented 9 years ago

Thanks for reporting. We will probably be using XEP-0280: Message Carbons to implement this, but I can't give an estimate because it's low priority.

webratte commented 9 years ago

It would be great if you could implement this before release the first stable version of the Desktop Client. Of course I know, there are much more important things to do...

daniele-athome commented 9 years ago

The main issue here is with unavailable resources, which as of XMPP rules don't exist until they come online. And things like Message Carbons only covers online resources.

abika commented 9 years ago

Some thoughts: XEP-0280 is only about syncing conversations FROM the server TO registered, connected clients. A complete solution must include a p2p sync between clients, unless we save messages on the server for some long time (which I doubt).

And whatever we do, it will require a lot of work...

daniele-athome commented 9 years ago

@abika p2p sync would require knowing which devices are linked together anyway, but that information can be kept into the clients themselves. Storing messages for a long time is a no-go :-)

abika commented 9 years ago

I see, we agree. There is no real XEP solution for this, which makes it even harder to solve this. Let's focus on group chat first

daniele-athome commented 9 years ago

Sure :-)

abika commented 9 years ago

The summer rain in Berlin produced some thought bubbles in my head:

How about using the message carbons protocol but extending it, so that clients can register for carbons at the server, and the server generates message copies for them, even if there are offline. Server will drop them, of course, if not retrieved by the client after some time. I guess this would be a good trade-off between full sync on one hand and workload and XMPP compliance on the other.

By the way, how long are undelivered messages kept on the server?

And a general problem are encrypted messages a client sends, as other (own) clients can't decrypt them. Client needs to send them additionally encrypted with own public key.

daniele-athome commented 9 years ago

I guess this would be a good trade-off between full sync on one hand and workload and XMPP compliance on the other.

It might work. But it will require implementation on the server (Tigase has Message Carbons, but it needs to be extended to support preregistered resources).

By the way, how long are undelivered messages kept on the server?

I configured it for a week. But I'd configure the period for carbons less than that. And also if a client doesn't login for sometime, it will expire.

And a general problem are encrypted messages a client sends, as other (own) clients can't decrypt them. Client needs to send them additionally encrypted with own public key.

All clients linked to a phone number account must have the same key (no multiple keys are allowed), so there is no problem here.

abika commented 9 years ago

All clients linked to a phone number account must have the same key (no multiple keys are allowed), so there is no problem here.

I mean a message a client sends to other user: The carbon of it should be send other clients (of the same owner), but these clients cant read the message as it is encrypted with receivers public key.

webratte commented 9 years ago

Why not enrypt strictly every message with receivers and senders key (like PGP encrypted Email)? You need encrypt every message with more then one keys also for group chat. So you have to implement this feature in every case (very bad English, I know :-/)

daniele-athome commented 9 years ago

Technically, the "key uid" is the same because the JID (phone_number_hash@server) is the same. JID is used as the key email field in the OpenPGP key. There are security issues to be addressed if using multiple keys because the key is used also for authentication, so I decided to allow only one at a time. It is also much simpler to think and use for users (one user => one key)