Comments (17)
@Chaphasilor, I'd be a FTC for this repo, but if you think it's a good first issue to start with, I'd love to give it a shot!
from decentralized-video-chat.
@bdlb77 that would be awesome!
take your time getting to know the repo and code, and if you feel confident you can implement this in a secure way somehow, just give it a shot and open a PR :D
from decentralized-video-chat.
+1 for this one, would be nice to have.
Maybe it could be helpful to have a look at how Jitsi (https://github.com/jitsi/jitsi-meet) implemented their "password protect meeting from within" feature.
from decentralized-video-chat.
@Chaphasilor
I guess it depends on how secure the call should be:
- Make the URL more unique with a "passsword"
zipcall.io/join/ChatRoom183x032-143d9
- All this will do is just make
- A Password token
zipcall.io/join/ChatRoom?password=183x032
- Now the tricky part is authenticating this password to check if its valid, but if there is no state on the server, there won't be a way to check to see what is the valid password for that call.
The first option is just creating a more unique URL and doesn't really do much of a justified "locked down call"
For the 2nd option, If WebRTC creates a peer-2-peer stream... The password can be stored in the metadata for a user and streamed to an incoming user who wants to join.. and if those passwords match then they could be authenticated and fully join the call.. Or something along these lines... Maybe I'm missing something that would make this a little easier? haha
from decentralized-video-chat.
@Chaphasilor so: a User joins and provides a password, in the server it pulls down the password of the Host by webRTC data (I don't know how else you'd query the Host's client without some other reference to the Host), and you check it in the server.
I'm not sure I understand fully that Heroku will wipe all data regularly. Will that happen while a connection is active to the call? I'd imagine this approach would use a Redis store
I'll work two of these examples and maybe it'll help give further light over which approach is more worthwhile.
- I'll do your suggestion of comparing password from joining User to that of the Host (which is pulled down from their client)
- I'll try it out with an in-memory storage solution
I should be able to show something in the next couple of days :)
from decentralized-video-chat.
Is it simpler to just have the user who created the chat approve new users who are trying to join, no password needed?
from decentralized-video-chat.
We could add this as an optional setting. I'm thinking of a 'lockdown' button that prompts the host for a password when they activate it and then every new user to join has to enter the password?
from decentralized-video-chat.
@Chaphasilor, I'm thinking of an approach similar to how Zoom does it:
A user enables the the "lockdown" toggle / button and it will generate a URL with a hashed token/password attacked to it at the end:
https://zipcall.io/join/ChatName?token=xxxxx-xxxx-xxxx
The user will also be prompted with this token as a chance to copy it to clipboard and they can pass it manually to others :)
from decentralized-video-chat.
@bdlb77 sorry for the late reply, I already replied in my head 🙄
The token-based idea is okay, I'd say, but this way users will have to copy and paste the token, instead of just telling the other participant the password. I know this is only an issue once lockdown is activated while the call is already going and a new user want's to join, but it's still an issue.
Imagine the following scenario:
A group of friends want to start a call using Zipcall and one of them sets up the call. He then pastes the link into a group chat. Some of his friends join through the link, then he enables lockdown mode. But some of his friends weren't ready yet and try to join later, which doesn't work without the token.
I think given that Zipcall isn't intended for business use, we could use a mix of token and password, i.e. a short token that is easy to remember (only numbers, or only hex, max. 8 characters). That should be secure enough but also easy to share.
Also, keep in mind that you'll need to update the call link and show it with a snackbar once lockdown mode is enabled :)
All in all your idea is good, just try to keep the token as simple as possible!
from decentralized-video-chat.
@bdlb77 yeah, I think the second option would be the way to go here.
Also, as you already stated, we'd have to do some serverless auth using WebRTC.
Maybe we could use the Zipcall server to check the pass token though, for example by requesting all currently connected users to send the current password and check if it matches the one provided by the new client?
This should be easier to implement than a fully serverless approach.
For a fully serverless solution you'd need every call participant to check if the new client's pass token matches their own one and only open a WebRTC connection if it does. I imagine this to be a bit more complex.
But I guess you should just try out both approaches, maybe we've missed something :D
from decentralized-video-chat.
from decentralized-video-chat.
@ianramzy you're referring to a different approach than the 2nd option correct?
The concern I have with using the server for authentication is that state would need to be introduced to persist a password that belongs to a video call. I think Node.js has this functionality to support in-memory storage (basic example: https://stackoverflow.com/questions/2219333/nodejs-in-memory-storage). There'd need to be some in-memory cache on server-side to persist Room Names and Passwords. Doesn't seem too bad to implement :)
@ianramzy @Chaphasilor Would you prefer this approach over a peer-to-peer authentication approach?
from decentralized-video-chat.
@bdlb77 well my first idea is using the server, maybe @ianramzy meant that?
If not, we'll have to be careful with server state, because Heroku will wipe all data and re-setup the server regularly.
I also dislike the idea of using a database for this.
from decentralized-video-chat.
@bdlb77 yep, something like that :D
Heroku will regularly 'move' the server, i.e. clone the repo to a new virtual server, start it and then erase the old server files. This means you can't save anything to the fs and server state will reset regularly. I'm not sure how connections influence this and I also don't know if the Zipcall server constantly keeps the connection alive, you'd have to check with the Heroku docs :)
I'm looking forward to what you come up with! <3
from decentralized-video-chat.
Is it simpler to just have the user who created the chat approve new users who are trying to join, no password needed?
since there is no user authentication, I don't think this would be a good idea, there are ways to bypass , something like the same name, etc.
from decentralized-video-chat.
do you know how the Whereby solution works? with locked room, and the owner of the room accept (or not) people to come in..
from decentralized-video-chat.
yes
from decentralized-video-chat.
Related Issues (20)
- Unable To Build (npm run build) HOT 25
- Simultaneous Conected HOT 1
- Features Request : Is it possible to record the video streams in each room as separate folder? HOT 11
- npm start doesnt work if i make any changes in the html files/any other files HOT 6
- Unable to connect to the same room HOT 7
- Video Camera not opening in live server HOT 1
- Webcam video not in proper resolution HOT 1
- Cannot GET error HOT 5
- webcam is not opening on live server HOT 1
- Call recording HOT 4
- Empty messages being sent in the chat HOT 1
- Can not call if custom setup for use case: user A have camera, but user B do not have camera HOT 1
- This project is currently inactive HOT 6
- username is required
- One two weeks ooms HOT 1
- Unable to install on CentOS 7 HOT 3
- Vlog
- How soon until group calls?
- Collab Suggestion For Metaverse Project.. HOT 5
- Cannot see the others' screen if I don't have a camera
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from decentralized-video-chat.