signal-csharp / signal-windows

Unofficial Signal Private Messenger for Windows

Signal-Windows

This is an unofficial Signal client for the Universal Windows Platform. It is (currently) a hobby project in a very early stage of production, so expect bugs and non-backwards compatible changes.

FAQ

What can it do right now?

• register as a master device
• be linked as a slave
• add/edit contacts
• send and receive text messages

What can I expect next?

• proper attachment handling
• syncing groups and contacts on linking
• a prettier interface

I want to try it out but I'm not a developer

You can get Signal-Windows from the Windows store with this invite link.

Support for completing CAPTCHAs is provided by CAPTCHA for Signal Private Messenger and its store link is here: https://www.microsoft.com/store/apps/9NXCBTL0SBPJ

Bug reports

Found a bug? Great! Open a pull request or an issue.

Contributing

See the contributing docs.

Legal things

License

Copyright 2017

Licensed under the GPLv3: http://www.gnu.org/licenses/gpl-3.0.html

signal-windows's Issues

cache signal sessions for better performance

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

display composed timestamp instead of received timestamp

update libsignal, save sent filename

filter duplicate messages like Signal-Android

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)

refresh prekeys frequently

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

handle delivery confirmation

save disappearing messages setting

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

remove disappearing messages when timer runs out

contacts view needs refactoring

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

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

possible solutions:

• enforce drained queue
• cache queue content

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

send proper sync messages to siblings

re-registering should be prompted when authentication fails

mismatchedeviceexceptions in pipe are not handled

improve store saving

we could:

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

UI needs to become responsive if we want it on phones

our early receipt cache is not reliable

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

the selected thread view needs refactoring

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

save color compatible to official ows devices

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

send attachments

design and icon parity with the official signal clients

would be a nice thing to have, obviously.

Signal-Windows complains about socket state during shutdown

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

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

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

selfmessages need special treatment

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.

handle receipts

contact changes are only visible after restart

basic handling of new identities

message view needs refacoring

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

display received sync messages

unknown groups are not created

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

re-registering should be possible

with an option to keep or discard your identity key

basic groups support

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.

verify our way of storing the signal store is not racy

outgoing messages need unique tagging to handle send confirmations

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

refactor store to comply with c# naming guidelines

ensure rowids are reset during link/registration

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

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

implement early receipts cache

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.

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