That implies it's a single payment, regardless of the duration of the call, which implies they are just using LN as a handshake to setup the call. Is this correct?
If that's the case, does anybody know why we haven't seen P2P video calling made possible over other protocols where a network/communication-layer (of any kind) is used to do the handshake. Eg. Why couldn't two people handshake over SMS? What is special about lightning, that is making P2P video calling possible?
It also means there aren't any servers in-between hosting the call, and that no one is mining your data and information, or is even aware that it's happening.
Over SMS your carrier would be aware of the action, and could stop or censor that interaction if required by an outside force, not to mention that there is basically zero protection of your data with SMS.
I may be wrong, but I think the idea here is the censorship resistance, privacy from prying data miners/advertising, ease of grouping a bunch of these services together, and no reliance other outside parties to get any of it done.
Imagine a chat / SMS system where you and the other party just moved back and forth the same 50 sats with each message. When you sent a message you were down 50 sats, when the other party responded you were up 50 sats...So the initiator minimally had to commit to losing 50 sats to send the first message....
The requirement of having to move value - no matter however small - is a huge deterrent to spam. If you wanted to spam 1M people, that would cost you 50M sats (~$21K USD)
This is what makes LN a unique P2P network for all types of transactions, as its inherently spam resistant to 99% of spam traffic.
It doesn't smell like they are doing that back-and-forth concept over lightning itself for the video transmission part. I'm trying to confirm this.
I'm looking to understand the architecture that maps to the language they used.
They say they are just using LN as a "signal and control layer" and they hint at WebRTC, which I personally don't know much about.
If they were using that back-and-forth concept, the call would cost something denominated in sats/second (right?). They are framing the cost as as a sats/call number. If it does end up being sats/call, the lightning network would be at risk of seeing fees climb to pay for this bandwidth. It'd end up with the same problem as Ethereum -- fees climb to the level the marginal buyer can afford and bids, screwing the initial use cases. And, plus, it'd be inefficient, and therefore slow/choppy-video.
All of their current language implies the two nodes communicate directly after establishing the initial 15-sat handshake.
It doesn't smell like they are doing that back-and-forth concept over lightning itself for the video transmission part. I'm trying to confirm this.
I don't claim to know how impervious is doing things, but you do understand that the way the LN network functions is based upon invoices, right? The entire premise of how messages are sent and routed are built on that concept....I'm not sure exactly how they could be routing 0 sat messages...minimally they need to pay node routing fees anyway....
I'm not sure exactly how they could be routing 0 sat messages
This is exactly why I'm assuming they are using some other tech, unrelated to LN, in order to achieve the 15-sat per call number (presumably after using LN to establish the "cryptographically secure data transmission channels"). We're on the same page.
don't claim to know how impervious is doing things
I'm looking for somebody, to guess at how they are doing it. The solution space feels small enough, and this community smart enough, such that we might get a near definitive answer via process of elimination.
Because...
video call = identity + handshake + video transmission
And, using LN, and the 15-sats, makes sense for handshake part but not so much the video transmission part. What tech are they using for the video transmission part?
If you don't know, or don't care to wager a guess...that's cool, maybe somebody else on SN could provide an educated guess. Or maybe, the Impervious team might even be lurking.
Do you know if the WebRTC transmission traffic would need to run ontop of LN? Apologies if this is a dumb question.
I read wikipedia, and it's talking about two other protocols (SCTP over DTLS) for transmission, that I don't know/understand...it doesn't sound like it would need LN, after the initial handshake.
WebRTC, which I personally don't know much about.sats/second(right?). They are framing the cost as as asats/callnumber. If it does end up beingsats/call, the lightning network would be at risk of seeing fees climb to pay for this bandwidth. It'd end up with the same problem as Ethereum -- fees climb to the level the marginal buyer can afford and bids, screwing the initial use cases. And, plus, it'd be inefficient, and therefore slow/choppy-video.video call = identity + handshake + video transmissionhandshakepart but not so much thevideo transmissionpart. What tech are they using for thevideo transmissionpart?