skynet-im / skynet-server Goto Github PK

When logging in on two separate devices with two separate accounts, the server sends packets sequentally. This means that one device has to wait for the other device to finish synchronizing. Depending on the dataset, this can take a loooong time. As there is no indication that content is waiting to be downloaded, the user may think the app has crashed, or even worse, that his data is gone.

A new confirmation mail for Skynet has to be designed.
The latest draft (download) by @Twometer for Skynet v4 can be used for inspiration.

Required changes:

• Username is no longer available after account creation
• Make use of $ADDRESS to show the account's address to the user
• Make use of $TOKEN to build the confirmation URL
• Show an Link as alternative if the button is not working
• Adapt the new design theme

Colors:

• Primary: #10304c
• Primary Dark: #0d273d
• Accent: #ffab40

Clients can currently send any dependencies as long as the referenced Message exists. The server should verify Dependencies to prevent clients from referencing messages from channels they are not a member of or referencing messages like MessageReceived or MessageRead.

The Skynet server needs a new concept to handle disconnects. Exceptions that occur while receiving the next packet are easy to handle. Sending a packet on the other hand happens asynchronously which makes it very dangerous to dispose objects.

Subsequent send calls should be omitted after a disconnect and packet sources should be disposed in order not to waste resources. To achieve this goal it might be necessary to inform several components about a disconnect. Generally, packets that could not be delivered can be discarded without notice as the protocol does not require the client to receive all packets that were sent by the server.

Some email providers make their customers accounts available on multiple domains or with additional labels. The Skynet server should detect this at register to avoid registering multiple accounts on the same address. There is information, how to solve this problem for Googlemail on StackOverflow.

When sending a ReceiveConfirmation message, the client attaches a dependency to the received message to it. However, the dependency is lost somewhere along the way so that the receiver cannot process the message and crashes.

Skynet has always been struggling with message state bugs. The server should include features to debug such problems. The database audit command should list all chat messages that have not been marked as delivered or read.

There are several race conditions that can lead the server to forward a channel message to client which has not yet received the respective CreateChannel packet.

This happens especially at session creation or restore before the sync has completed and when a new channel is created with its channel members in one database transaction.

The Skynet server has to handle some secrets such as KeyHash, SessionToken and WebToken. These secrets are not sufficient to read encrypted messages but an attacker could leave a foreign account in a corrupted state and could bypass a future server sided brute force protection.

Storing the SHA-256 hashes of the respective secrets would be the easiest solution for this issue.