dollyvolley/low-key

low-key

The messenger client is a web app and allows for secure and private communication. It distinguishes from other because it runs without a central provider. It consists of a client software for the users and a distributed ledger technology for the communication between them. The data exchanged between chat participants is completely private, meaning no one from outside can tell what, how often and even when messages are sent.

---

Issues

This application suffers from two severe issues, both connected to the state management. The particular areas where the issue is detected is mentioned as comments in the code.

• removal of other pending msgs during confirmation of primer ones (scenario 1 in the code comments)
• loss of newly received msgs if other chat is not visible during the time of arrival (scenario 2 in the code comments)

Stack

• SPA: React 18
• State Management: Context
• PWA
• DLT for communication: IOTA
• DLT adapter (send, interpret and organize data and transactions): IOTA Streams Channel (publish/subscribe tool)

Technical Particularities

True Privacy

The benefit of the PWA is the Service Worker, which allows for fully cached application in the browser. This makes it "offline" usable, but **a custom iota node should be selected to go fully invisible. **

Limitations

The architecture of DLTs in general comes with certain properties, some technical particularities have to be dealt with.

• Write access: No entity can send an arbitrary amount of transactions.
• Message size: As the data needs to fit into a transaction, it's size is limited to 32 kB
• Persistence: The DLT won't store data forever (for the transactions we are using here), this means the clients can only retrieve it for a certain period of time

low-key's Issues

Multi Msg Post

When multiple messages are posted during the time the first is still confirming two issues arise:

• after the first message is confirmed, the msgs coming after it are removed again
• all messages are received at the other end, however only certain ones are persisted.

These two issues are very likely connected and rooted in the state management.

Set custom node

Allow users to set a custom node used for streams

Fix stream dependency in state

Context

The Channel state contains:

• meta information
• messages
• streams client

Since the streams client needs to be converted before it can be used it requires the async import to finish before a channel might be opened.

To solve this issue the streams client will get it's own state, making the persisted data independent.

Task

Add a new atom for the streams client
Add an atom indicating the streams loading state
Protect stream dependent functions with that atom

Add PWA

Add global message sync service

Context

Currently stream channels only get synced when it is opened.

Task

Create a task queue for the message service (as clients can not be used concurrently).
Create a service which syncs all clients in an interval
Add UI to inform user when a new message was received

Message Sync Service Halts

After a certain time, or after a yet undiscovered event, the message service does not receive any new messages.
Reloading the application fixes the issues.