Other users should be able to click on an "Open external session" button in order to introduce a session ID and connect to it

We have a restriction because we're using the same public key we use while communicating with all our peers.

We should refactor to have an execution flow like the following one:

1. User A creates a new session: whatever.com/b3e2757a-d31f-41f7-ba3b-d0d18fd2fd46
2. User B tries to connect to the user A session
3. User A sends out his/her append only log public key to user B in order to replicate the DB

From #40

When a second user opens the same session but before he introduces its nickname, it appears in the Users list as Anonymous. This could be confusing for the users already in the session because they could think that someone has joined and can actually see the contents of it (something not true yet).

However, I wouldn't vote for changing this behaviour grimacing. Instead, I would go for leaving the user land right in the editor of an existing session and letting him edit his preferences afterwards. That is, not asking his nickname before joining the session. The main reason would be to reduce the friction with the user to the bare minimum while joining a session. This is something similar to what http://zoom.us does while joining an existing conference session

If we go for this approach, it'll be definitely useful to list new session joiners as Anonymous until they set their nickname slightly_smiling_face

P2P Editor crashes while loading its home with querystrings in the URL.

• How to reproduce: Open http://p2p-editor.codely.tv/?pacharan
• When does it happen: For instance, social media platforms such as Facebook usually add querystring parameters even if you don't add them manually to the shared URL:
  • Facebook post example
  • URL generated by Facebook

How to reproduce

1. User A opens a new session
2. User B joins the session and starts seeing how A type and following his/her careet
3. B makes a click moving out the caret to another position
4. A continue typing and moving out the caret
5. B continues to see the new text modifications but s/he has missed the caret position of A

What would be expected

• Ideally, the user B would recover the caret position once user A makes a modification after B has modified the caret position (4)
• However, as a quick solution, we could make user B (and any other read only users) unable to set a new caret position

Adapt UI size to mobile and tablet clients. Right now it's too small, and it allows to zoom-in and out.

Add a button in the UI in order to let the user save a snapshot of the current code as a GitHub Gist.

This way, we could do a future feature in order to start a session from a previously saved Gist.

In order to improve development experience setup webpack-dev-server

Current Dockerfile implementation is designed for production environments. Replace it with one for development.

README.md sections (##)

• 📜 Table of Contents
• 💡 What does P2P Editor do?
• 🤔 Why P2P?
• 🏗️ Architecture
  • Communications (Swarm & WebRTC)
  • Append only DB (Hypercore & Merkel Tree)
  • Storage (RAM)
  • Signalhub (Distribute connections)
  • Ace (Editor)
• 🚀 Environment setup
  • 🐳 Docker environment
  • ✅ Run the tests
• ℹ️ About
• 🤝 Contributing
• ⚖️ License

Inspiration

• 🎯🐘 Hexagonal Architecture, DDD & CQRS in PHP Symfony
• 🚀 CodelyTV dotfiles

He have several dependencies with known security vulnerabilities.

Would require the dependencies upgrade process modifications on our end due to public API changes? Or would it be something painless? 👼

• Restrict the loaded assets to the main programming languages:
  • JavaScript
  • PHP
  • Java
  • Scala
  • Bash
  • Markdown
  • Kotlin
  • C
  • C++
  • C#
  • Go
  • SQL
  • CSS
  • HTML
  • ¿?
• Add a selector in the UI in order to let the user specify which language s/he wants to write in

Didn't we changed the default port to something more random to avoid collisions with common local development environments?

Suggested port: 3617 (the closest numbers to the edit word I can think of right now xD)

This would imply also:

• Modify the Docker Compose P2P Editor port mapping
• Modify the Docker Compose Signalhub port mapping
• Modify the default SIGNALHUB_URL environment variable value

When a user opens P2P Editor in a browser that does not have WebRTC support, we need to tell him/her to upgrade his/her browser.

Message

P2P Editor can't run in your browser 😞
Please, upgrade your browser or try it in another one.

Implementation suggestion

webrtc-swarm has a property for checking if browser supports WebRTC https://github.com/mafintosh/webrtc-swarm#swarmwebrtc_support

Browser support:

• Browsers WebRTC support by caniuse
• Browsers WebRTC support by Wikipedia

Context

The application is gaining traction in terms of stabilizing the codebase and we're close to the 1.0 milestone. Congrats! 😬🙌

Because of that, I think we should do something in order to avoid losing the trace between issues and their corresponding changeset (Example: issue - changes) 👼

Why not to apply a classic PRs workflow yet

I understand that we're still in a very early stage of the application and we need to bootstrap the skeleton modifying a lot of times the very same lines of code.

If we apply a classic Pull Requests workflow (waiting for PR review and so on), we could make the experience a bit frustrating:

• Conflicts: Having to wait until a PR is merged in order to have the modifications available so we avoid conflicts because of modifying the same code
• Incremental changes: We wouldn't have the previous PR changes in order to develop further features based on that one.

Even if we could workaround that, for instance, concatenating PRs opening them based on the previous one; it could end up also being frustrating because of requesting changes on the first PR of the chain would make to apply it rebasing or merging all the concatenated PRs branches.

Proposal

For this reason, I would suggest to open a PR per issue even if we don't block the PR merge. That is, we wouldn't have to wait for a PR approval in order to merge it.

This way we'll only modify master through PRs merge commits (not pushing commits directly to it). That leads to exposing the different changes we're making (so anyone can actually see why we're making those changes), and be able to trace when and how an issue has been solved.

Furthermore, we'll allow to let anyone review the change set made due to a specific issue and provide feedback even if it has already been merged.

What do you think?

When a new version of P2P Editor is deployed, changes are not visible until the browser's cache is cleared.

This is happening beacuse the name of the static files (main.js, main.css, etc.) is not modified in each new version.

Current architecture:

All write operations are performed by the peer initiating the session:

• Single write database owned by session intiator.
• Previous database is replicated to the rest of peers for reading.

We have some features that need all peers to be able to perform write operation like:

• set its display name
• set the position of its cursor
• enable/disable peer audio
• take edit control

Proposed architecture/solution:

Allow write operation to all peers:

• Each peer has its own writable hypercore DB.
• All write operations of a peer are stored in its own DB
• When a connection to a peer is established via WebRTC, we perform DB replications:
  • we replicate our database to the connecting peer
  • connecting peer replicates its database to us

In summary, each peer has a write hypercore DB and a read hypercore DB for each connected peer.

In this architecture, when a peer performs an action that wants to publish (for example: CHANGE_DISPLAY_NAME action), he/she simply store the action in its own DB. This action will be recieved by all peers by replication, and they will react to this action.

After a lot of try, error and documentation, I have a working prototype of this architecture that uses WebRTC datachannel, that we can translate to P2P Editor.

This architecture can be plugged easily with Redux and any frontend framework like React and Vue.

Other options that I have try without success:

• Use signalhub for nickname, cursor, etc. communication: discarted because is a non P2P solution
• Use SimplePeer to send raw data (peer.send()) in the same DataChannel: discarted conflicts with hypercore replication
• Create new DataChannel in SimplePeer to send raw data -> multiplexing already not available.

With the current session storage (RAM) when the user reloads the page the session is lost. This is also a problem for development, because session is lost for each code change due to webpack dev server hot reload.

Here are listed web storage available options.

Allow to select a user from the connected users list and follow him/her

That is:

• Enable Read only mode
• Follow the caret movements
• Show selected text as highlighted

Detected in #40

After setting display name WebRTC connection is being lost, and for that reason the name disappears for some seconds.

In fact, if you closely look at the 13th second of the video, you'll see how the Anonymous text is firstly replaced by the new nickname guest and after that, it disappear for ~10 seconds.
https://monosnap.com/file/la0NldV5KwAmETRiYsVv5642kM0oSV

🤔 What

This will be the base feature in order to let us add further features in the next Milestones.

👤 User flow / UX

• A user clones this repository
• Run a Docker Compose in order to locally execute the web app (Example: localhost:8338)
• The application generates a new document ID and redirects to it (Example: localhost:8338/0d69a7c0-e04d-4ffd-9490-f4901a0bdeba)
• The user can share the unique ID and other users can access to the very same session through their local copy of the application

🚀 Use already available JS libraries in order to communicate using WebRTC or WebSockets. We could keep the high level abstraction by the moment in order to simplify the project bootstrap

💡 Centralized web apps used as inspiration

• http://3v4l.org
• https://scastie.scala-lang.org

Setup ESLint in order to maintain a consistent JavaScript code style.

Comparision of code styles

Detailed comparision:
https://medium.com/@uistephen/style-guides-for-linting-ecmascript-2015-eslint-common-google-airbnb-6c25fd3dff0

Best known code styles:

• ESLint recommended https://eslint.org/docs/rules/
• https://standardjs.com/rules.html
• https://github.com/airbnb/javascript
• https://google.github.io/styleguide/jsguide.html

ESLint setup

• Official doc: https://eslint.org/docs/user-guide/getting-started
• ESLint loaded for webpack: https://github.com/webpack-contrib/eslint-loader
• Tutorial: https://www.robinwieruch.de/react-eslint-webpack-babel/

Example

Add more "P2P eXperience" features:

• Ask for a nickname while opening an existing session
• Show the list of connected users to the current session

Blocks: #8

Take advantage of WebRTC to build a communication audio channel between peers.

In order to modify configuration between different environments / installations, setup dotenv.

Replace hardcoded values with:

• SIGNALHUB_URL