z5labs / chatio Goto Github PK

Having a unique protocol per call requires peer discovery to try and dial everyone until a match is found. For very large networks this could be an issue.

I'm lazy and suck at art so this'll be pushed back until most likely audio/video work

Make sure manifest.json is properly configured for 'Add to Homescreen' functionality.

Blocked by #7

Currently, any number can be entered in the call id field for Join and it will "join" that call. While this is useful for testing purposes, it is most likely not desirable for production.

To keep MVP development moving at a quick pace this is blocked until #11 is completed.

An initial implementation of this could be simply listing the peer ids from the peer store.

Most likely implement the js-libp2p-webrtc-star tool star-signal in Go and deploy it on Google Cloud Run.

Add button for generating/viewing invite link for a running call

Currently, the call id is used for specifying the protocol nodes communicate with it. This leaks the call id via the libp2p protocol negotiation which then opens an unnecessary attack vector for bad actors to take advantage of. A potential solution is to mandate a password for each call for encrypting each call id, as well as, using a non-unique protocol for at minimum chat messages.

See #25 for discussion about a non-unique vs unique protocol

When testing on a single computer/local network, devices can be rate limited to due Too Many Requests to the signalling server to discover more peers. A simple fix is to lengthen the interval with which the rendezvous server is called. This should also be configurable in some sort of advanced settings section

Initial Thoughts

The underlying WebRTC transport needs to be accessed from the libp2p node or a new WebRTC connection needs to be established for streaming audio and video while text messaging and call management goes through the libp2p network.

Whenever a new job uses the cached node_modules instead of installing fresh, the Quasar CLI reports:

Error Unknown command "build"


  ___                             
 / _ \ _   _  __ _ ___  __ _ _ __ 
| | | | | | |/ _` / __|/ _` | '__|
| |_| | |_| | (_| \__ \ (_| | |   
 \__\_\\__,_|\__,_|___/\__,_|_|   
 

  Running @quasar/cli ***.2.1

  Example usage
    $ quasar <command> <options>

  Help for a command
    $ quasar <command> --help
    $ quasar <command> -h

  Options
    --version, -v Print Quasar CLI version

  Commands
    create    Create a project folder
    info      Display info about your machine
                   (and your App if in a project folder)
    upgrade   Check (and optionally) upgrade Quasar packages
                   from a Quasar project folder
    serve     Create an ad-hoc server on App's distributables
    help, -h  Displays this message

  --------------
  => IMPORTANT !
  => Trigger this inside of a Quasar project (and npm/yarn install) for more commands.
  --------------

Even though it's not the most secure approach to starting calls but that tradeoff can be determined by the user. This feature should not be the default user experience. For example, the auto-generated id could be prefilled in the call id and if the user would like to they could delete it and type in whatever they want.

Some Quasar CSS is using will-change to hint to the browser about a property which will be animated at some point. However, Firefox retains this hint for too, consuming too much memory and potentially hurting performance. For more see, “Will-change memory consumption is too high” firefox issue?.

Default to peerId

I have so far come across a weird issue in firefox when trying to connect to another LAN device. The error recommends having a TURN server in the case of STUN failing. This may be avoidable by leveraging libp2ps' circuit-relay protocol but further investigating must be done to determine which could provide better bandwidth and latency.

Firefox WebRTC Error:

WebRTC: ICE failed, add a TURN server and see about:webrtc for more details

Have a basic form for new call specific settings like password

IndexedDB is most likely the best bet for persistance since it provides a larger storage capacity and is more reliable than localStorage.

Only allow github action to push to gh-pages branch