signal-csharp/signal-windows

Unofficial Signal Private Messenger for Windows

signal-windows's Issues

ensure rowids are reset during link/registration

otherwise the (signed) pre key offset(s) are wrong

move the OutgoingCache access to the MessageBox

In MessageBox::MessageBox_DataContextChanged we have actual control over when the UI element is constructed/pinned to a SignalMessage. This could require a second cache though, in case an update arrives when the MessageBox is not yet existing.

Or we could force a layoutupdate.

cache signal sessions for better performance

could boost our performance a little as they are read quite often

contact changes are only visible after restart

design a proper way to block for db actions

As soon as a message is on the wire, both the receiving and the sending task want to change the message entity to keep track of the status and receipts.

proposal:

• delay send until message is saved to db
• use transactions for receipts and status

pro:

• simple
• safe

con:

• increased outgoing delay

block contacts

unknown groups are not created

UI needs to become responsive if we want it on phones

implement text search for conversations

For efficient full-text search we should use FTS tables.

Unfortunately, until now EF core does not support this (dotnet/efcore#1590) and it is not yet planned for any milestone.

Possible workaround: https://stackoverflow.com/a/36051020/1569755

outgoing messages need unique tagging to handle send confirmations

design and icon parity with the official signal clients

would be a nice thing to have, obviously.

save disappearing messages setting

improve store saving

we could:

• save to a tmp file and switch atomically
• use the db

send proper sync messages to siblings

basic handling of new identities

the selected thread view needs refactoring

We want to step between search results and scroll up indefinitely, so the current design will not do.

registration page needs overhaul

It should:

• not be ugly
• not allow wrong usage (e.g. sending verification code before requesting one)
• allow restarting the procedure
• notify the user if errors occur

visible (and synced) unread states

selfmessages need special treatment

save color compatible to official ows devices

implement early receipts cache

Signal-Windows complains about socket state during shutdown

https://github.com/dotnet/corefx/issues/5340
https://github.com/dotnet/corefx/issues/5200

remove disappearing messages when timer runs out

messages appear to be sent twice to the recipient's first device

finalizing our first db migration

We should get our first version of the database stable asap, and use migrations if we have to alter something later.

Things we could/should do:

• rename SignalThread to SignalConversation?
• switch to ulongs everywhere where foreign keys are involved
• add a reference to the last unread message of a SignalConversation?
• create a table for EarlyReadReceipts, since a read receipt might arrive before the message
• use separate db for the libsignal-protocol-stores?
• save "special* messages like group/disappearing messages updates and session resets

message view needs refacoring

status (sending, senttoall, receivedbyone, readbyone) and timestamps would be great

Signal-Windows crashes when the websocket server closes the connection

tldr: nothing we can fix or workaround, we have to wait for a new System.Net.WebSockets.Client release.

https://github.com/dotnet/corefx/issues/17317

Stacktrace:

System.Exception: Exception from HRESULT: 0x80072EE2
   at Windows.Networking.Sockets.MessageWebSocketMessageReceivedEventArgs.GetDataReader()
   at System.Net.WebSockets.WinRTWebSocket.OnMessageReceived(MessageWebSocket sender, MessageWebSocketMessageReceivedEventArgs args)

mismatchedeviceexceptions in pipe are not handled

refresh prekeys frequently

this needs access to the SignalProtocolStore, which should only be accessed with the SESSION_LOCK acquired.

display received sync messages

message order of received messages is incorrect

If the device has many messages in the queue, it will save them in the wrong order when connecting

update libsignal, save sent filename

contacts view needs refactoring

unread messages count, last message, timestamp and avatar would be nice

UI updates the status of an outgoing message only if no other thread has been selected in-between

handle delivery confirmation

ensure messages in the dbthread's queue are not excluded when loading a thread

possible solutions:

• enforce drained queue
• cache queue content

re-registering should be possible

with an option to keep or discard your identity key

handle receipts

filter duplicate messages like Signal-Android

display composed timestamp instead of received timestamp

refactor shutdown code

the resetevents are unneccessary and we can speed up the shutdown if the device is unregistered.

We should save the join handles of our worker tasks and join them on shutdown.

re-registering should be prompted when authentication fails

basic groups support

send attachments

our early receipt cache is not reliable

most likely we are comparing the wrong timestamp. will investigate.

our ThreadsDictionary contains stale data when receiving messages while the device is locked

Further ThreadListItem updates "fail", because the view attached to the model is not the view on the screen.

Also in general, strange things happen when the UI is supposed to be updated while the device is locked.

handle and display received attachments rudimentarily

• save attached to message
• restart failed downloads on startup
• display if finished
• wait for wifi? https://stackoverflow.com/a/32846579/1569755

constant message order should be enforced

Currently, the position might change after a restart due to two tasks (receiving and sending) racing for the db, while the UI has to display the message immediately.

Having the UI wait for the db insert to solve the dispute is not an option.

Deferring the db access is also not an option, because the signal server wants its messages confirmed asap, and we want to keep the bookkeeping overhead minimal.

tl;dr:
Constraints:

• We want the UI to display an outgoing message immediately. This implies that the UI thread must be the one deciding the order of messages.
• onMessages must not return before the messages are saved
• insertion of outgoing messages is deferred

Conclusions:

• receive must coordinate insertion with UI

Possible solution(s?):

• UI maintains a queue, receive may invoke insertion and block for completion, dedicated task saves to db and unblocks receive

verify our way of storing the signal store is not racy

refactor store to comply with c# naming guidelines