mihanentalpo / cryptboard.io Goto Github PK

Perhaps it is worth redoing the entire correspondence system to a more classic "chat":

1. List of recipients on the left
2. The "all recipients" item, where everyone is located
3. Filtering incoming messages by whether the sender of the message is in the selected chat or not
4. Then you will have to display your messages separately, without actually sending and receiving, but indicating "to whom it was sent", then you can display messages in those chats where there is a recipient

When receiving information about the name, write "Maybe John", in red, when pressed, inform that this recipient introduced himself in such a way, which is not necessarily true, and the opportunity to accept this name.
If the name is accepted, then Maybe word disappears.
If a name has already been given, then Maybe is displayed along with it.

To be able to add the key, using a screenshot of the QR code copied and pasted on the PC.
It is also logical to make it possible to open a QR code file or drag-n-drop such a file

The main page "/" - make it informative so that the newcomer does not get confused.

For those who have already used the system, immediately give the main buttons - Go to clipboard, Share key, Add key

For those who haven't used it yet, show quick, super-simple user manual.

1. The main function is to show the addition via QR code and anonymity
2. Additional features - pass key by reference

It would be great to make a video and post it on youtube.
In general, entire home page can be made as a landing page, where all the functionality is summarized.

Весь блок редактора текста сообщения и кнопки под ним - должны быть целью для drag-n-drop файла (и не одного)

When the clipboard page opens, before the messages have been rendered - it is necessary to display the loader spinner, if there are no messages - write "no messages yet"

Also, messages are now only rendered for the first time after the first successful fetch of the list of unread messages from the server, although the messages may well already be in the browser by the time they are downloaded.

Make it possible, at the user's command, to enable the ability to permanently store settings in the browser.
Thus, when you click on the skull and bones, some of the settings will not be reset (settings related to the functionality, for example, "mute notification sounds" and in the future some others

Hi,
I am experiencing the following behaviour on my local installation. The user keys are expiring every few days. So, when the user connects, new keys are generated and have to be shared again. Can you add a configuration on the validity of the keys?

Кнопка которая очищает все сообщения, но не вообще всю сессию

In the absence of the Internet, show some kind of loader with a status, and do not allow sending messages

Add interface for user so it would be possible to specify custom public and private RSA keys.

Из-за навигации по хэшам фронтенд не сможет быть проиндексирован поисковиками, и нельзя при вставке ссылок со страниц генерировать превьюшку для соц-сетей и мессенджеров.
Нужно сделать нормальную навигацию, продумав как это сделать правильно.

Messages that are already on the list should be able to be sent again to everyone or only to one person

Need to check and set EXPIRE for all keys. The exception is the keys that SPECIFICALLY should be stored for a long time (in the future planned persistent data storage)

https://www.ietf.org/archive/id/draft-irtf-cfrg-cpace-06.html

Now, when each next piece of the file is received, the loader icon starts spinning again

Switchable sound notifications, with unobtrusive but not like in other apps sounds

Create android application base on electron with initial functionaliy:

• The main application code
• Functionality to select custom backedn server (to make it use self-deployed server)

When a new version is released, prompt the user to refresh the page indicating what's new in this version.
For this:

1. Need to store the version somewhere
2. Somewhere to store the history of changes between versions (in different languages)
3. Somehow read the version from the back (for example, once every few minutes)

1. Если такой ключ уже был на момент получения - не отображать сообщение
2. В самом сообщении вставлять аватарку того чей ключ был прислан

Maybe make it possible to generate a link to add a key immediately with some special parameter indicating that specific data is expected, so that when a person adds a key using such a link, a message "ready to accept a password from you" is automatically sent.
This kind of message would probably need to be signed with a hash, and in order to prove it to be true, the hash would have to be sent back when the request was received.

Then the script will be like this:

1. Send a link to a person
2. From the person comes the message "ready to accept the password"
3. We send the password.

There are also disadvantages: if the message is intercepted, then there is no way to know who exactly is ready to accept the password.

Need further research

1. Finish work on moving all content pages into Markdown, in a separate locale folders
2. Write (or use already existing) some kind of simple wrapper for javascript and php getText functionality
3. Walk through all the UI code and wrap all messages in a wrapper (2)
4. Build *.po and *.mo files for default locales (en_us, ru_ru)
5. Add tooling for easy creating of new translations

So that you can change an already sent message and it would be replaced by remote recipients, if they have it, and if not, nothing would happen

Save the time of arrival in the message, add the time in the message icon block, display the full date-time when hovering the mouse

1. Сгенерированный QR-код рендерить на канвасе
2. Из канваса выколупывать data:base64
3. Класть в сторэйдж
4. Вставлять QR-код в виде картинки чтобы на нём можно было нажать правой кнопкой "копировать"

To make it easier to implement new versions of UI, and to use "logic" code on server via node.js, the "logic" code must be decoupled from UI code.

So, steps, that are need to be done:

0. Read all the javascript code in files: frontend.js, shared.js. There not so much code, and it's well documented. It's needed to understand the whole picture, and to make decision on refactoring.

1. create three separated files:
   1.1) core.js - for the core functionality, such as exchanging data with server, storing data in browser
   1.2) ui.js - for all the UI drawing functionality that are responsible for drawing user interface, and working with user interaction
   1.3) app.js - central application file that is used as a "glue" between UI and core, initialization and all the intermediate work

2. At first step of decoupling - just move functions and objects to this three files, for example:
   2.1) lib.ui, lib.clipboard, lib.tabs, ui.modal elements into ui.js,
   2.2) lib.avatar, lib.files, lib.tools, lib.state, lib.log, lib.storage, lib.msg, lib.ajax, lib.receivers, lib.client and some other little objects - into core.js
   2.3) lib.core - into app.js

3. After all the code is refactored this way, and still in a working state, walk through result files, and search for fields and methods that are not belongs to the module. For example, some method of creating HTML-UI-code used to open Modal window from the core module.
   For example:
   3.2) lib.msg.check_new_and_draw calls lib.msg.check_new() and than UI code lib.ui.draw.messages() and this could be done in app.js as a glue code - first access core.msg.check_new() and on promise resolvation - ui.draw.messages()

4. Create some kind of simple event system, so, events that fired from core component could be attached to some UI handlers (for example, new message arrived). Cross-tab system for such events already exists, and it's located in lib.broadcast, allowing to send messages that are captured by all the tabs. But it's not so fast as usual JS events, and in most circumstates is looking like overkill.

5. Move all coupling between core and ui into app.js, by using events and promises. So, core code must know NOTHING about UI (except, maybe avatar and QR code generation, that could be useful in node.js code also).
   For example:
   5.1)lib.receivers.receiver_changed calls UI code lib.ui.receivers.window.update_if_opened(uid) and lib.ui.draw.receivers()
   5.2) lib.msg.add_msg uses lib.ui.msg.types to chck if arrived message is of one of specified types. But this is wrong, there could be more message types than some UI supports. So there should be separate list of types in core module.

After all of that, we already would have a working application, where ui.js and app.js could be replaced by rewritten on any other JS framework.

We send this request from time to time.
If the user is alive, he sends the answer back.
Thus, we know that he is, firstly, alive, and secondly, that we still have the correct encryption keys with him.

If several such packets were sent, but there is no response, we mark the user as "possibly dead".
If the answers came, or the user himself sent the same packets, then he is alive again and we can send packets again.

Can you consider adding multilingual support? I can help translate the zh-CN version.