Oddbean new post about | logout
 This is my vision as well. I really liked the proposal with rendez-vouz beacons and webrtc for those side channels. What spec are you thinking of using? 
 So, passing over Bluetooth and internal WIFI is very easy (which was my first test a few weeks ago). I just started doing some WebRTC tests and looking at some server alternatives and signaling needs. It works but I am very early in this whole adventure. 

I looked at Rendez-vouz as well and I was wondering can't we just pass the signaling through our usual relays instead? Maybe we still need some type of STUN server to get the phone's IP and as long as two users can use different STUN servers, it could work. 

What I want to avoid is replacing our replays with a different "relay". If we need to use a server to transfer some info we can just use our regular relays instead to avoid another dependency/attacking point.  
 This was proposed forever ago.
https://github.com/nostr-protocol/nips/pull/363
Useful perhaps? 
 Yep, it was what started this whole think for me :)  
 How is that working out? 
 Yes I think using nostr relays to setup rendezvous is a great idea, with hole punching something like this https://itnext.io/p2p-nat-traversal-how-to-punch-a-hole-9abc8ffa758e

What lower level protocol are you thinking of using? UDP messages? TCP with message framing added back? WebSockets? If we are starting a new protocol, can we go binary? 
 Support this 
https://github.com/markqvist/Reticulum 
  ✅ Optimism Airdrop Round 2 Is Live! 

 👉 https://telegra.ph/optimism-09-02 Claim your free $OP. 
 We will need to go binary for voice and video calls. But for the messages that are just simple nostr events, I am not sure if it makes sense since the event is already in text.🤔