Closed adambabik closed 4 years ago
Not sure I fully understand, but currently there are already rules to match a message against a chat, these are tight to the channel we receive the message on, mainly for security reasons:
We look at a field {:content {:chat-id "x"}}
, let's call this self-reported-chat-id
, and message-type
.
message-type
is group-user-message
: We use self-reported-message-type
to check the user is actually in the group-chat with id self-reported-group-chat
and has joined the group-chat. A chat should not be created automatically.:user-message
and the message is coming from us (same pk), we blindly trust self-reported-chat-id
. That means is a pairing message. This is also bound to change as signatures are now not only in whisper, so eventually pairing messages will not fall under this category but the next one.:user-message
and the message is not coming from us, we only trust the signature of the message, self-reported-chat-id
is discarded, and a chat-id
is recovered from the siganture (currently chat-id
= 0xpk-of-the-sender
)Is that what you mean or I misunderstood?
@cammellos this issue is about collecting these rules and implement them in status-protocol-go as well as describe in the specs repo. I know we have them because chats work but it's hidden knowledge in status-react.
Is that what you mean or I misunderstood?
That's exactly what I needed :) In the console-client, I implemented recently (still in progress) matching of messages of type :user-message
. I will continue with :group-user-message
but needed confirmation.
And as mentioned above, I believe this implementation should live here because this lib already implement chats. Do you agree?
Also, we want this to be a part of the protocol specs, unless you already did it at some point.
And as mentioned above, I believe this implementation should live here because this lib already implement chats. Do you agree? Yes, I agree.
Also, we want this to be a part of the protocol specs, unless you already did it at some point.
I don't think is documented anywhere, good point
Agree on documenting these hidden behaviours. Do either of you want to issue a PR to the specs repo?
@oskarth The only thing that's left is private groups. Other type of chats are covered in https://github.com/status-im/status-protocol-go/pull/66.
@cammellos Can you point me to the code that creates a private group chat ID?
EDIT: I found that it's uuid + admin-public-key-hex
. Is that correct?
EDIT: I found confirmation in our spec: https://github.com/status-im/specs/blob/master/status-group-chats-spec.md#chat-id
As a developer, I would like to have incoming messages linked to an instance of
Chat
so that I can match incoming messages to chats and vice versa.Problem
v1.Message
has a propertyChatID
.Messenger
exposes methods to manageChat
s. The problem is that there is no direct connection between one and another.ChatID
fromv1.Message
is aChatID
from the sender perspective so it cannot really be used by the receiver. There must be another way of matching a message to a chat. It may happen that there is no chat for an incoming message. In such a case,Chat
instance should be automatically created.We need to establish rules how a message is matched against a chat.
Acceptance criteria
Chat
instances for public, one-to-one and group messages.Chat
instance.cc @cammellos @oskarth