nips
nips copied to clipboard
nostr-protocol
NIP-100: WebRTC Signaling over nostr
This NIP allows for nostr ephermeral kind 25050 to act as a signaling layer for Peer-to-peer WebRTC connections
Potential Uses:
- Video Conferencing App
- Nostr Nests over nostr
- Discord-like app
- Direct Phone Calls
Rough Demo: https://nrtc.jacany.com
This is fine, but I wonder how much it is tailored to a single application but it is posing as a generic thing without actually being generic.
This is fine, but I wonder how much it is tailored to a single application but it is posing as a generic thing without actually being generic.
Any changes that would make it more generic? If you're talking about the "room" that's just a common identifying keyword for clients to subscribe to.
Concept ACK! We've been talking about WebRTC signaling via Nostr in the TG channel here and there for a year or so, great to see it formalized.
Any changes that would make it more generic?
I don't have any changes to suggest, I don't know if it should be more generic. Maybe it should be more specific. A NIP for the entire concept of app calls, for example, would make sense and allow calls apps to be interoperable between them. That would make more sense than a pseudo-generic "webrtc NIP". I am just throwing ideas.
How do clients learn of other client ids / public keys? There's a broadcast message, so does that get pushed to the other clients in the room then? And the relay tracks who is in each room?
Broadcast message is listened to by clients subbed to that “room", once they hear it they know that’s a new client to connect to. Discovery of these “rooms" is not a feature because it supposed to be general purpose,
I should probably rename rooms to like address
On Mar 16, 2023, at 4:22 PM, John Williamson @.***> wrote:
How do clients learn of other client ids / public keys? There's a broadcast message, so does that get pushed to the other clients in the room then? And the relay tracks who is in each room?
— Reply to this email directly, view it on GitHub https://github.com/nostr-protocol/nips/pull/363#issuecomment-1472684924, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHMFQVE3MNXGYNEOODFA5SDW4NY7DANCNFSM6AAAAAAVZYDCV4. You are receiving this because you authored the thread.
So for connecting clients would they first push out the broadcast followed by the ICE candidate broadcast? Should other clients wait around for the ICE broadcast to come through before attempting a connection to the other peers?
If Alice is waiting a room for Bob and receives Bobs initial broadcast, she won't know if she should wait a moment longer for his ICE details before attempting connection or not.
Probably out of scope, but messages which allow a peer to request another peer to mute their microphone or video would be helpful, would be up to the peers / environment to determine to actually honour the request / demand. Even if it was just a toggle on the client "Allow others to mute me".
Though suppose you could transmit this type of data over the peer connection rather than Nostr...
However, if you were to broadcast your mic / video state, new connecting peers could determine if a lack of a video stream is due to a connection fault, or it being turned off.
So for connecting clients would they first push out the broadcast followed by the ICE candidate broadcast? Should other clients wait around for the ICE broadcast to come through before attempting a connection to the other peers?
If Alice is waiting a room for Bob and receives Bobs initial broadcast, she won't know if she should wait a moment longer for his ICE details before attempting connection or not.
https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling#signaling_transaction_flow You can also watch this process happen in real time by opening https://nrtc.jacany.com on two different devices and opening the console on both of them before enabling microphone, it's all logged to the console.
Probably out of scope, but messages which allow a peer to request another peer to mute their microphone or video would be helpful, would be up to the peers / environment to determine to actually honour the request / demand. Even if it was just a toggle on the client "Allow others to mute me".
Though suppose you could transmit this type of data over the peer connection rather than Nostr...
However, if you were to broadcast your mic / video state, new connecting peers could determine if a lack of a video stream is due to a connection fault, or it being turned off.
I'm confused here, clients can locally mute a peer. No need to ask the other client to stop transmitting.
Client disconnects are typically detected by the other peer ~5 seconds after it actually disconnected so it's almost negligible. Though this time only considers when the tab is forcibly closed (like closing the browser tab or force quitting an app), when a client wants to disconnect gracefully they can send a type:disconnect and it'll instantly be closed.
I just meant in the event you've got 4 peers in a group call, where someone mutes the mic of another and it's reflected across all connections just like Zoom does it.
Have you got a link to the source code of https://nrtc.jacany.com/ ?
I just meant in the event you've got 4 peers in a group call, where someone mutes the mic of another and it's reflected across all connections just like Zoom does it.
Oh I see. That's Out of Scope for this NIP because I believe because that's the client's job.
Have you got a link to the source code of https://nrtc.jacany.com/ ?
https://github.com/jacany/nrtc
I was just thinking of doing something similar, but instead of having rooms I just want a simple audio / video call application where people can call me using my pubkey.
Shouldn't room id be optional in that case? I understand that for traditional webrtc signalling room ids were needed, but I don't understand why they are needed for direct calls in nostr.
The reason why I believe it would be important to specify the direct phone and video call use case is that I believe we should have both separate apps for voice / video calls and probably some clients will want to integrate it.
It would be also cool if I could click call / video call in a nostr social network client on an author and that could open an external app that can handle the call.
Shouldn't room id be optional in that case? I understand that for traditional webrtc signalling room ids were needed, but I don't understand why they are needed for direct calls in nostr.
The spec could be modified to that room id and pubkey can do the same thing. ex: pubkey for one-on-one and r for group settings.
Sure, any solution is good, I just think it should be written in the spec so we can play around with apps that do that (your code looks easy to modify :) )
I love this NIP. Potentially even more could be done over WebRTC like gossipping about relays or possibly even publishing each others notes (in a large enough webrtc pool this might help obfuscate IP's?)
What do we need to do to progress on getting this merged?
What do we need to do to progress on getting this merged?
Just more clients implementing it. I know there is a 500k sat bounty for iris to implement this.
This should probably be merged with https://github.com/nostr-protocol/nips/pull/498.
@fiatjaf could this be merged please? i believe it has been implemented inside of 0xchat
It seems like this is not just for voice/video but would also support bootstrapping a text channel as well. This could make having a relay in the browser possible with no additional software:
- Do WebRTC signaling over nostr via an existing relay
- Start WebRTC data channel
- Send and receive Nostr events over WebRTC in full duplex connection
I don't know the particulars around WebRTC for >2 participants, but if it's possible to do group video calls it must be possible to do a group relay type thing.
I maintain my previous opinion on this. More concretely: it is not really a standard if it doesn't specify what clients should do once they get the webRTC connection, i.e. what messages should they send and what should they expect in return.
Also 0xchat as far as I know has not implemented anything that is compatible with any other app, they're making their own custom stuff with no regard for standardization or interoperability, so it's hard to get a grasp of what is really there or not.
I maintain my previous opinion on this. More concretely: it is not really a standard if it doesn't specify what clients should do once they get the webRTC connection, i.e. what messages should they send and what should they expect in return.
I think that's because it's so generic. It's really an application-to-application basis. Maybe the proper path forward would be to change this.
Also 0xchat as far as I know has not implemented anything that is compatible with any other app, they're making their own custom stuff with no regard for standardization or interoperability, so it's hard to get a grasp of what is really there or not.
Good point.
Will give this some more thought on how it can be improved, thanks.
I maintain my previous opinion on this. More concretely: it is not really a standard if it doesn't specify what clients should do once they get the webRTC connection, i.e. what messages should they send and what should they expect in return.
Would it be sufficient to suggest things with MAY? The initial discovery/signaling is pretty clear cut but thereafter there is a lot of flexibility inside WebRTC. People use it for voice, video, any live p2p syncing, chat, etc. I don't know that adding the entire WebRTC solution space to the NIP is the move.
I don't know enough about Nostr, WebRTC, or 0xchat to comment much more.
I think this is excellent. Can this be improved by indicating uses such as "video call", "voice chat" or "send/receive nostr events over webrtc" in this nip?
I maintain my previous opinion on this. More concretely: it is not really a standard if it doesn't specify what clients should do once they get the webRTC connection, i.e. what messages should they send and what should they expect in return.
My position is that it would be valuable to have a basic WebRTC NIP (like NIP-01) that other NIPs build upon (the audio calling NIP builds on the WebRTC NIP) I would rather not have multiple NIPs that all implement their own weird version of WebRTC signaling. I guess that's what the goal of NIP-100 is right now.
My position is that it would be valuable to have a basic WebRTC NIP (like NIP-01) that other NIPs build upon (the audio calling NIP builds on the WebRTC NIP)
I see, so this nip is about leaving the rest to other specifications once the signalling is done. I thought it was similar to nip-59 and nip-17 in that it separates the underlying methodology from the specific solution to make it more generic.
I've built my own rtc signaling for nostr and i'm now looking into adapting it to this nip.
I have some suggestions:
- always require a roomId even for one-to-one connections (a room of two people), since it makes the implementation easier as it doesn't have to handle two special cases
- do not encrypt 'r', since encryption cannot be used to broadcast the 'connect' event to a specific room before knowing its participants. Instead the spec could suggest to use random or otherwise non sensitive room ids.
- For authentication (password protected rooms), the events should use an optional preshared secret instead of relying on the encrypted 'r' tag.
