Currently got the linux tests running on gitlab.
Side note: Apparently, pull-requests across forked repos (i.e. from us contributors) don't trigger builds on gitlab cd/ci which is a big shame.

So we want:

• linux binaires
• osx binaries
• windows binaries
• handle release tags automatically

Currently if a user has set a password then the password dialog is shown at the start.

In the case that the user forgets this password, there is no way for them to completely reset their database other than manually navigating to the folder storing the info and deleting that.

I propose adding a button on the password dialog which allows the user to delete the db, starting completely from scratch.

Thoughts @sachaaaaa @BeaudanBrown @KeeJef

Bug description

The toast notification for receiving a new message will say you have one more message than you actually do if you haven't focused the window since receiving a friend request accepted message

Steps to reproduce

1. Send a friend request from A to B
2. Minimise the messenger window on A
3. Accept the friend request on B
4. Send another message from B to A

Actual result:

A will receive a notification popup that will say "2 New Messages"

Expected result:

A should receive a notification popup that just shows the single new message

Platform info

Operating System:

Linux

Bug description

When you are adding a new contact they don't show up in your contacts list until a message has been sent or received after they have been added as friends.

Steps to reproduce

1. Send a friend request from A to B
2. Have B accept the friend request

Actual result:

The conversation for A and B is only shown in the "Conversations" tab but not the "Contacts" tab until another message is shared between them.

Expected result:

The conversation should appear in the "Contacts" tab for B as soon as they have sent the accept friend request message and for A as soon as they receive the friend request accepted message.

Potential solution:
electron-userland/spectron#144 (comment)

Bug description

Need to confirm if happens for both messages and friend requests.
When sending fails, clicking on Retry Send triggers a

retrySend: Attempted to retry, but no numbers to send to!

Steps to reproduce

1. disconnect from the internet or stop the localhost http storage server
2. Try to send a friend request
3. reconnect
4. click "Retry send"
5. Notice how nothing happens, check the logs for the error message

Currently we blindly reply to all broadcast messages coming from storage with a ping.
We need to debounce those replies to limit the number of pings we send consecutively to the same contact.

currently default TTL is 24 hours for regular messages. We should allow this to be edited to a certain extent.

Disable drag n drop until we support attachments.

Bug Description

We set a friend request timeout timer to allow people to resend friend requests if they might have been cleared from the storage server, but it also triggers after the friend request exchange has been completed

Steps to Reproduce

1. Perform friend request exchange
2. Wait 4 days

Actual Result:

Friend request status on the initial friend request sender gets reset to none

Expected Result:

Both parties should remain friends

Hi,

I'm a lokinet contributor and was having a look at this repo but I don't see any issues nor mentions of where discussion typically takes place, etc.

Is anyone able to give me some pointers on this? I'd like to contribute to the messenger.

All says signal, and why we may want to conform so changes can go upstream, we may want to update to include any of our own changes.

• I have searched open and closed issues for duplicates

Bug description

Steps to reproduce

1. step one
2. step two
3. step three

Actual result:

Expected result:

Screenshots

Platform info

Signal version:

Operating System:

Linked device version:

Link to debug log

Bug Description

The online status logic is only working for one half of the participants for a lot of cases

Steps to Reproduce

1. Start two clients and complete the friend request exchange
2. Take client 1 offline
3. Bring client 1 back online

Actual Result:

Client 1 broadcasts their online status, client 2 receives it and responds with a ping but client 1 does not put client 2 as online

Expected Result:

Client 1 should think that client 2 is online

I shafted this one with some of my last few changes I think

We have just been manually downloading the bootstrap.signed file from one of our toynet nodes and going from there when we want to join our messenger toynet

Since we will probably be wanting other people to start testing the messenger soon (and messaging each other) we should make it easier to set up lokinet properly to do so

We should create a simple script similar to the default lokinet-bootstrap command which downloads am identity file from our vps for a user to plop right in to their lokinet folder

How this is actually used is still up for debate

• Should the messenger itself try and "install" this file in the user's lokinet folder? (seems complicated)
• Should a simple script be in the root of the github?
• Should we just put a link to one of the identity files with instructions on the github?

Once #179 is done, we can show the setting to the user.

The windows build sometimes takes ages which causes travis to terminate it after 10 minutes because of no output generated.

Increase this to 30 minutes or something.

Probably should sign our binaries on mac and windows. Not sure about linux?

Currently link preview actually uploads the thumbnail to the Signal server as an attachment.
We can work around this by simply re-performing the link preview when receiving the message.

We have decided to run a HTTP server on each of the messenger clients which can receive messages with a similar API to the current storage server running on the nodes.

All lokinet instances have an ephemeral snapp when running which can be used to access the HTTP server if the server is bound to 0.0.0.0

Clients will use the regular Signal protocol (post friend request handshake) to share their .loki addresses to each other, and then make periodic POST requests to these addresses to maintain a list of which of their friends are online.

The current flow envisioned for how this process would work is as follows:

A and B establish a Signal protocol session together through the current friend request system

• This is a Pre-requisite for sending p2p messages

A starts the application

• use localhost.loki and X.X.X.X.in-addr.arpa.loki to aquire a list of .loki addresses that A can be contacted through.
• Broadcast a message (type: p2p-address-broadcast) to all of our friends via the Service Node (snode) Storage Server.
  This message should also contain A's .loki address.
  • The TTL of this message needs to be short (~1 hour or shorter)

B comes online and does the same routine as A.

A receives a p2p-address-broadcast message from B and does the following:

• Add B's loki address to our memory and mark B as online
• Send a p2p-address-broadcast message to B's loki address rather than a Service Node.
• Again this type of message always contains A's .loki address
• B receives this message and adds A's loki address to memory and mark A as online

Whenever a contact is marked as online, we always send to their .loki address directly rather than a Service Node. We can also ignore the pow and ttl fields in the message.

Flow of maintaining "online" status:

To check whether a contact is still online, we need to ping their .loki address to see if we get a response.

We want to avoid the following when doing it:

• Only ping every X minutes as not to flood the other user
• Avoid both users pinging each other at the same time

We also have a timer which keeps track of when we were last contacted by the user. If a user doesn't contact us within that time frame then we mark them as offline.

We can infer is a user is online if they POST some data to our server, at which point we can reset the online timer.

The following is a use case:

• A receives a POST request to their HTTP server with B's .loki address + a signature from B
  • respond with 201 and starts a heartbeat timer
• B receives A's 201 response, marks A as "online" and starts their heartbeat timer
• B's timer completes and B sends a POST request to A with a signature

This process repeats until the contact is unreachable. At that point we set that contact to offline.

Bug description

You cannot delete messages of a conversation in a row.

Steps to reproduce

1. Delete messages to a conversation
2. Try click delete messages again

Actual result:

The delete dialog doesn't appear.

Expected result:

The delete dialog should appear.

Bug Description

When a user send a friend request, their profile is also sent along with it.

Steps to Reproduce

1. Open up 2 different messengers
2. Set a profile name on one of them
3. Send a friend request to the other messenger

Actual Result:

You get the profile of the other user when they sent you a friend request but haven't accepted or declined

Expected Result:

The profile should only be sent on a friend request accept.

Replace the icons in images/icon_x.png

Currently we set a contact as offline as soon as we fail to send him 1 message via P2P.
Once marked as offline, we have no way to restore the P2P session unless one of the two participants restart their application, which would send a broadcast message.

When we are online, we currently only send a broadcast message (or ping) to our online contacts. Maybe we should attempt sending a ping to all contacts for which we have a .loki address stored in memory.

Not sure if this is just caused by lokinet being slow to start or there is something weird about the 'onEmpty' logic or whatever but the app thinks you are offline for a while when you boot it up

The status would be shared as part of the ping message.
The ui would then display a different colour based on the status.
This is obviously just a UI thing, since a "offline" status would still be visible from the debugger.

During discussions with the messenger team, we realised it would be currently pretty easy to create thousands of key pairs and spams users with thousands of friend requests.

So we need a way to prevent this.

There are solutions on the client side, using whitelists etc. but at the expense of a diminished user experience (if you get spammed and enable a whitelist feature, it will be more difficult for new contacts to send you friend requests easily).

Other solutions would be to allow users to verify their pubkeys, for example by service nodes.

Something like

1. user creates an account, gets a pubkey
2. user asks multiple random service nodes to start verification
3. service nodes each send a riddle (CAPTCHA) that the user needs to manually answer (no automation possible here)
4. if the riddle is answered correctly, the service node signs the user's pubkey
5. Next time the user sends a friend request, it would send the verification proof with it, which is basically a list of signatures and corresponding service node pubkeys.
6. Anybody can then decrypt those signature and validate that they were provided by existing service nodes.

Signal has an additional encryption layer between the client and the server for the outer proto message, which we have disabled in Loki Messenger.
From memory, the client generates a symmetric key upon registration and sends it to the server during the registration process. It is referred to as signalingKey in the code. Once defined, that key doesn't rotate. It seems that key is used to decrypt messages coming from the websocket interface (not sure if/how the outgoing outer messages are also encrypted).

So we need to

• audit what metadata is sent in the clear at this stage by the Loki messenger.
• check how much security Lokinet provides for those unencrypted metadata (from memory, anybody in the local network can read those messages? Need to confirm)
• implement channel encryption between client-client and client-storage server if deemed necessary

I don't know the intended behaviour, like do we want to disable sending messages to ourselves?

Currently we can't send a friend request to yourself

We need to have more detailed error handling for the service node requests
For example we need to make sure we are only removing nodes if the request times out (node is unavailable), but should be able to tell the difference between a node being down and our internet or lokinet not functioning

Need to make sure we have thought about how we are handling edge cases, e.g. some requests have succeeded but not enough to meet the threshold (we may need to just treat this as a success because if we try to resend the message with a new PoW then people would get duplicate messages)

Need to make sure that messages which have had no successful responses get added to the retry queue properly

Sealed senders is a feature from Signal.
We need to investigate if/how we want to integrate that as well in Loki messenger.

We need to investigate if it's possible for someone else to "steal" a prekey bundle intended for a contact and use it to start a session.
The friend logic might already be preventing some of this, but we need to cover the edge cases as well (e.g. we decline a friend request from someone then they steal one of our prekey bundle intended for someone else and use it to start a session with us?)

Implement this

// Currently /store
Headers: [X-Loki-EphemKey: ...]
body: { // Encrypted with EphemKey
  method: store,
  args: {
    pubKey: ...,
    ttl: ...,
    pow: ...,
    timestamp: ...,
    data: WebSocketRequestMessage // Encrypted with signal
}

// Currently /retrieve
Headers: [X-Loki-EphemKey: ...]
body: { // Encrypted with EphemKey
  method: retrieve,
  args: {
    pubKey:...
  }
}

Possibly /storage_rpc ?
EphemKey would be a key pair generated by client as frequently as desired (per request, per session, keep key forever)

Bug description

On the production build, sometimes while sending messages, they will time out by the background worker. This also makes it so retrying send fails

Message.saveErrors: Failed to retrieve new device keys for number 05380cd14da7c0b8b4cb5100776346c7f5d6c2ffecdae26d9313710e5c37c03a11 TimedOutError: Worker job 2 (calcPoW) timed out

ERROR 2018-12-14T05:20:53.648Z retrySend: Attempted to retry, but no numbers to send to!

Steps to reproduce

1. Send a message
2. While the first message is sending, send another
3. The second message will fail
4. Retry send

Actual result:

Message failed to send and failed to retry send

Expected result:

Message should send correctly or retry sending should work.

TODO

• Fix timeout issue
• Fix retry send

When offline, the logic doesn't wait (long enough) before re-trying to hit the /retrieve url.
CPU gets hogged without doing anything.

Bug description

When you accept someone's friend request, they can't see your self assigned profile name until you have sent them another message

Steps to reproduce

1. Have B set a profile name
2. Have A send B a friend request
3. Have B accept A's friend request

Actual result:

A doesn't see B's profile name until he has received another regular message from B

Expected result:

A should be able to see B's profile name as soon as he has received B's friend request accept message

Currently when a user A sends a message to user B, user A's state would be set to requestSent and user B's state would be set to requestReceived.

Once user A sends the message, it has 72 hours before that message expires.

The problem occurs when this message expires. So going again with the flow above:

• user A sends to user B.
• user B doesn't reply for 72 hours.
• user A's message gets expired and the state gets set to none

What would happen if user B now clicks accept on the received friend request? User A's state would be none but user B's state would be friends which is incorrect behaviour.

window.textsecure.createTaskWithTimeout throws a timeout consistently in production when sending a message. Probably related to PoW, or a promise not being resolved/rejected somewhere.

There's no way of copying the public key of a contact that you have.

If we send a message via p2p then those should be coloured differently to indicate the p2p stuff.

libloki-protocol.js is getting a bit cluttered with vaguely related functions that we just want to access globally through window.libloki

To make this stuff easier to find/maintain/etc we will split these into different categories (e.g. window.libloki.crypto or window.libloki.storage) and also group these into separate files to be grunted into libloki.js

1. Launch messenger
2. Do not start the server
3. Send a friend request to a random pubkey
4. Start the server
5. Notice how the friend request doesn't get sent

Bug Description

When you send messages to a person and they all fail, when you reload the messenger, only the last failed sent message remains.

Steps to Reproduce

1. go offline
2. send multiple messages
3. reload

Actual Result:

Only the last sent message stays

Expected Result:

All of the messages that errored should stay

Signal has stuff built in for multi-device flows but i don't think we utilise it yet.

Currently the seed is only viewable on the registration page.

Setup Travis CI so that any incoming pull requests from another branch are automatically tested.
Gitlab CI doesn't allow this at the moment.