BridgeMessage is a type of chat message content which will be sent from Matterbridge.
It contains fields:
- bridge name - depends on the used bridge, eg. "discord", "slack", etc...
- user name - username the message was received from
- content - message content
- user avatar
- message id
- parent message id - used in case of replies
Message is saved to a separated table: bridge_messages, similarly to discord messages.
The user_messages table is untouched.
bridge_messages table contains user_messages_id in order to join with user_messages table.
Issue #13098
This PR fixes [9947](status-im/status-desktop#9947) and contains :
- Commit to fix the changing of custom picture and having the change
reflected on contact's side
- Commit to fix the deleting of picture and having the change reflected
on contact's side
- Rename confusing `ImageType` to `ImageFormat`
* feat: don't remove sent mutual state messages on accepting a CR
* fix: don't send mutual state message for a new contact
* chore: move mutual state messages to `addContact`
* fix: use one chat for mutual state messages and contact requests
* fix: change `added` mutual state updatede messages to `accepted`
* feat: Use different content type for each mutual state event system message
* chore: use constants for mutual event system messages test, review fixes
* chore: fix tests related to local contacts map
* feat: add mutual state update system message
* feat: send mutual state update on accepting CR
* feat: send mutual state update when removing a contact
* fix: don't send MutualStateUpdateMessage over wire
* fix: mutual state update message text fixed
* fix: new clock to ensure system message after CR and add chat to the response
* feat: add AC notification for contact removal
* feat: replace "sent" mutual state system message with "added"
There were a couple of issues on how we handle pinned messages:
1) Clock of the message was only checked when saving, meaning that the
client would receive potentially updates that were not to be
processed.
2) We relied on the client to generate a notification for a pinned
message by sending a normal message through the wire. This PR changes
the behavior so that the notification is generated locally, either on
response to a network event or client event.
3) When deleting a message, we pull all the replies/pinned notifications
and send them over to the client so they know that those messages
needs updating.
Why make this change?
We are adding support of audio recorded files, similarly to how we did
with images
What has changed?
- Added protobuf definition, only AAC supported
- Added migrations to store files
- Fixed an issue with nil pointer when transaction would fail to be
created, causing the application to crash
This commit adds support for images in protobuf messages.
The client can specify a path which will be used to load the image
and set the corresponding fields.
This makes the assumption that the RCP server runs on the same machine
as the client and they have access to the same files. This holds
currently for both status-react and status-console-client, we could
revisit and adds an upload if that changes in the future.
This commit pegs the clock value to maximum + 120 seconds from the whisper
timestamp.
In this way the we avoid the scenario where a client makes the timestamp
increase arbitrarely.
This commit does a few things:
1) Handle membership updates using protobuf and adds the relevant
endpoints.
2) Store in memory a map of chats + contacts for faster lookups, which
are then flushed to disk on each update
3) Validate incoming messages
Sorry for the large pr, but you know, v1 :)
Mykhailo Prakhov
Michal Iskierko
Godfrain Jacques
Andrea Maria Piana
Mikhail Rogachev
Boris Melnik
Pascal Precht
yqrashawn
Richard Ramos
Jonathan Rainville
Samuel Hawksby-Robinson
andrey
Volodymyr Kozieiev
Pedro Pombeiro
flexsurfer