search

muke1908 / chat-e2ee

End-to-end encrypted disposable chat & audio-call sessions, exchange sensitive information with peer safely and securely.
https://chat-e2ee-2.azurewebsites.net/
Apache License 2.0
349 stars 207 forks source link

General features suggestion #128

Closed Narasimha1997 closed 3 years ago

Narasimha1997 commented 4 years ago

Provide a Dockerfile that will help users/contributors to quickly setup and test the app locally as a complete package. Providing a Dockerfile will also help us deploy the application on any machine, on cloud or on native metal.

Also try to separate frontend and backend as much as possible so that the frontend can be served by any static hosting solution and backend can be deployed as a managed container on any cloud.

Scalability can be difficult because the entire backend is a monolith. Try separating them and package individual in their own containers, so that they can be scaled independently. (Also try to add Kubernetes support in future, make it cloud native)

Assymetric encryption can be slow for large files, provide alternative solution for encrypting images, encrypt the byte stream or base64 representation of the image.

Use managed object storage service like minio to store image data in encrypted format as objects. Minio can scale well and can be used as a gateway for Azure Storage, AWS S3 or GCP GCS, it can also be deployed as a Object storage abstraction on local storage hardware.

muke1908 commented 4 years ago

@Narasimha1997 Thanks for your suggestions! Dockerizing - definitely it's something to work on.

Also try to separate frontend and backend as much as possible so that the frontend can be served by any static hosting solution and backend can be deployed as a managed container on any cloud.

Scalability can be difficult because the entire backend is a monolith. Try separating them and package individual in their own containers, so that they can be scaled independently. (Also try to add Kubernetes support in future, make it cloud native)

The scope of this project is highly defined and limited (BFF architecture suits well), separating into FE and BE will create additional overhead. Based on the project scope, the backend doesn't fit in the microservice architecture.

Assymetric encryption can be slow for large files, provide alternative solution for encrypting images, encrypt the byte stream or base64 representation of the image.

There is some alternative idea for image sharing - https://github.com/muke1908/chat-e2ee/wiki/Idea:-Secure-image-sharing

Use managed object storage service like minio to store image data in encrypted format as objects. Minio can scale well and can be used as a gateway for Azure Storage, AWS S3 or GCP GCS, it can also be deployed as a Object storage abstraction on local storage hardware.

The data is not being stored anywhere. It's just relayed to the client.

Narasimha1997 commented 4 years ago

Any plans to implement electron.js client for desktop??

muke1908 commented 4 years ago

@Narasimha1997 That would be a nice thing to have. But need to carefully plan a build process. Is there anything you already thought?

Narasimha1997 commented 4 years ago

As the first step, we can use ipcRenderer to render the react app in electron window. Later we can think of building a electron specific app.

Narasimha1997 commented 4 years ago

As a quick setup we can use nativefier while we build the electron app.

muke1908 commented 4 years ago

nativefier looks pretty cool! Did you try it before? In case you tried with this project, let's write a doc (in readme / wiki page) on: How to do it - Instruction, Setup, Installation etc.

Narasimha1997 commented 4 years ago

Sure! I had tried nativefier for one of my projects. It worked pretty well. It just creates an electron native window and links to our website.

Narasimha1997 commented 4 years ago

Able to generate the native binary. Made a PR as well.

147