Toggle encryption per-user

[daniele-athome]

A menu item to toggle encryption on a per-user basis. It must be persistent of course.

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

[h-2]

What is the reasoning behind this issue? Why shouldnt everything be encrypted? Or is this just for communicating with regular jabber users?

[daniele-athome]

Yes, mainly for that.

[webratte]

Hi,
is there anybody out there who could fix this issue.
I know, @daniele-athome has not enough sparetime to do all the Jobs. (BTW thank you for working hard for Kontalk! )

I have a very important contact (my wife ;-)) with a regular XMPP client on here PC in her Job.

And currently I have everytime turn of encryption for ALL contacts to chat with her.

[abika]

Ill start working on this within the next week. Haven't done much lately.
Preliminary task list:

• context menu (for chat or per user?)
• add to database
• add "noEncryption" parameter flag to {where encryption is done}

[webratte]

Thanx :-)

I think per User or Chat it's both OK.
But maybe per User would be the Better choice because in future you can extend the menu with things like "show typing notification", show "reading notification" and so on.

[daniele-athome]

@abika thanks for volunteering :-) A few pointers for you, probably some of those you knew already.

Offline/online table

Two copies of the users table are kept: users_offline and users. The offline version is the one that is read from the user interface. The online version (users) is the one filled in by the sync procedure. Once sync is completed, users_offline is truncated and contents of users are moved to users_offline, all in a single transaction.

Users table is volatile

The users table is considered to be volatile. That is, all information is deleted during sync and the table is filled in again from scratch with data from local contacts and server. This means that an "encryption enabled flag" can't be stored in users.

Where do you store the encryption enabled flag?

As I see it, there are three possible ways:

• change the sync behaviour to drop this delete-all-fill-from-scratch with another approach so we can store it in users (costly)
• store it in the threads table: this will be lost if the conversation is deleted (not desirable)
• store it in another table in the users database, linked via the jid column to users (as @webratte said it could be used also for other information)

@abika what do you think?

[daniele-athome]

Other pointers for the user interface:

• agree on a context menu item inside the conversation, wherever the information will be stored (a contact info screen is not ready yet and is much more costly to do right now)
• global encryption preference is retrieved from Preferences.getEncryptionEnabled. I tried to keep calls to this method as few as possible (the boolean value is then passed from method to method), but you'll have to replace all of them with another method, falling back to the global preference when no value is available (this depends on how you store the information though)

Thinking more about the additional table required, I was also considering a users_preferences table with columns like this:

• JID
• key (encryption_enabled, typing_notification, also other stuff such as notification ringtone etc.)
• value

So we can store any type of preference in the future, falling back to default values if no data is found for a user. Comments welcome here of course :-)

[abika]

Thanks for the detailed explanation. However, after thinking about this I would really like to make this a chat specific setting. Because

• Chats are (imo) pseudo persistent i.e. they are normally not deleted and re-created by the user - ever. And so having often to re-set the encryption does actually not happen.
• The encryption does "take place" "in the chat" from the user point of view. If a message is encrypted or not is visible in the chat view and the setting should be not "too far away" to change this. (Hope you get what I mean)
• About group chats: encryption is turned off only for one of the group members. What happens with outgoing messages? The discussion can get very long here... But if making encryption a chat setting the answers are very simple.

And yes, it is a user based setting in the Desktop client but I would probably not design it like that again if I would start from scratch.

[webratte]

OK, for encryption I agree absolutly.

But if you insert also things like special ringtone for users. hide last online and hide typing message and what ever you implement in future?

If I delete this chat (I do that sometimes ;-)) , I have this things set again.

In this case "per user" would be the better choice.

And, hopfully, in future turn of encryption will be not needed anymore because all XMPP clients using the same standard for encryption ;-)

OK, groupchat is a problem.
That's right.

Maybe you simply should not accept users without encryption in groups.

BTW. I'm sure min. 90% of Kontalk users use Kontalk and not XMMP Clients wich not compatible with the current encryption in Kontalk.

[webratte]

I have just thought about the problem with groupchat.
And your right. It's not so easy how I thought.

If a group member start a unencrypted 1 to 1 chat there will be a really big problem....

I forgot this :-(

[daniele-athome]

Ok I agree with you, let's encrypt the conversation. It means altering the threads table then.
I'm not thinking about other customizations right now (e.g. Ringtones) because if we store the encryption setting per-chat, other customizations become out of scope.

In the future, when implementing OX/OX-IM the decision of using encryption or clear text will be almost automatic. But we'll discuss this another time.

[daniele-athome]

Merged in 6feb4a3.