[feature suggestion] Group chat content should be optionally static

[yurivict]

Group chats should be optionally static with the content stored on one or several master hosts. It should be possible to assign the stable user account or accounts to keep the history of all communications in the group chat, including the attached documents.

This feature will be very useful in the small business/family context. The group chats could be topical, last for a while, have documents attached to them, and their history browseable by all participants at all times. Also the list of such static group chats should be optionally browseable by all friends of the master user.

An article about the commercial messaging app Slack (https://slack.com) inspired me to make this suggestion. The major selling point of Slack is the ability to have persistent chats with an attached documents. They promote this as an e-mail replacement. And they proved that there is a significant number of users and businesses that would like such feature.

I believe that such feature is quite implementable within the tox system, although it may seem like a stretch now.

The company could run the static account that has all the history, all employees being friends with that account. So all employees would be able to see all chats that this host is a master of and join them and see the content.

It looks and behaves like a cloud, except it isn't really a cloud.

[GrayHatter]

@JFreegman

[ProMcTagonist]

I know @JFreegman has commented in the past that group history isn't feasible to do in a trustworthy way, but the option to sacrifice total distribution for chat history is something small familiar groups would love, and that many deem a necessary feature for adoption.

[AMPBEdu]

I don't understand why don't we have everyone sign each message they send in group chat with their private key and then have every client connected to the group chat save all the messages and fill in the holes that are missing in other clients, and every client can check that each message is legit from a certain profile by checking it with that person's public key. Boom working group chat history, without being able to spoof messages unless you have that person's private key.

[JFreegman]

@AMPBEdu How do you verify the signature of a peer who's offline? Where do you get his public key from and how can you be sure of its authenticity? A malicious peer could just create a new keypair, sign a message with your name attached to it, and send it to everyone after you go offline, claiming it came from you.

[AMPBEdu]

@JFreegman what if the public key was baked into the tox id somehow? Then the public key would be tied to one and only one tox id.

[JFreegman]

Tox ID's have nothing to do with groupchats. Your Tox ID is not exposed to group peers.

[AMPBEdu]

@JFreegman Oh, what if everyone establishes their public key when they join the group chat? Edit: Oh, then people who join while your offline won't know your public key. Is there a reason tox id's aren't exposed to group peers and also associated with messages? How can you tell some one who is sending messages is who they say they are?

[JFreegman]

Is there a reason tox id's aren't exposed to group peers and also associated with messages?

The reason is that people may not want to associate their Tox ID with groups that they join.

How can you tell some one who is sending messages is who they say they are?

Who they are is determined by their group ID. If they say they're someone from your friends list then you can't verify it, unless you do so out of band.

[AMPBEdu]

@JFreegman So then howabout we let people join group chats with their tox id, or let them generate a pseudonym id to use rather than their tox id. They will both have a public key included. Then you can verify that the chat logs are correct, while also maintaining pseudo anonymity (and they can easily throw away the pseudonym).

[JFreegman]

@AMPBEdu That's not what the issue is. Even if you used Tox ID's it wouldn't solve anything.

[AMPBEdu]

@JFreegman I guess I don't understand what the issue is then O.o

[AMPBEdu]

Okay just to be clear here is what I'm proposing: Every client has a public private key pair, and the public key is part of the id of who you say your are. When you send a message, it is signed by your private key and sent to everyone in the chat along with your tox id/pseudonym id. Each client can verify that message was sent by that id by unencrypting it with the public key in the id (at least I think thats how signing works), and also saves the message history and will share with others to fill in the holes who can also verify whether the messages are from the id that the message says its from. If a malicious peer generates a new pair, it would also in turn generate a new id, so when they attempted to send a message as you it would show as another person entirely.

[aaannndddyyy]

AMPBEdu, the point is that you do not use the pubkeys and privkeys for actually signing and verifying message authenticity. Actually, no chat messages are signed at all in tox. Signing creates a global proof of authorship , that's not desired. Read about otr, and what features it has. Tox protocol tries to achieve the same goals, but is not as sophisticated. So as there are no signatures, it does not solve the problem if you change the identifiers used for chat.

It is a limitation of the protocol.

Options are:

• Lose deniability and sign chat history
• Do without a chat history
• Have a trusted authority, a (few) central peer(s) per group who store and testify
• Have an "untrusted" history à la "This is what was said before, according to peer X, but X is not necessarily telling the truth:"
• Change to a modern protocol like axolotl