Kim Dotcom will launch his own browser-based video app. He wants to kill Skype by providing a browser to browser application to chat and create a video connection. Things will be fully encrypted from computer to computer. Probably with a back-end on on the Mega-servers.
How will a Skype-like videosystem work on SAFE? I’ve learned that there can be as much as 20 hops between 2 users. With so many ip-connections before the video gets to you friend on the other site of the planet, a lot can go wrong. If only 1 hop goes offline your connection is lost. Will a scatter-gather approach be used for a videochat? Are chunks created? Or is that to slow for live video?
Maybe a way is to create some parallel connections using different nodes. Let’s say 7 connections, 5 for the live-data to go over different hops (and ip-adresses) and 2 for a RAID data for error correction. Don’t know if that’s possible.
For voip and (one to one at least) gaming etc. al the network will do is connection establishment for the nodes. So these will be direct udp connections and as fast as they can be.
The details to be worked out are,
1: Should the network fully encrypt such traffic or leave to app devs to do that. In any case this part is pretty straight forward.
2: For multi user voip and gaming etc. we need to supply decentralised serverless capability. It can be crudely done for a few users, but not in a scalable way (so I don’t like it ). This can take a few forms though and in this case I feel we will have to provide network level API’s to allow negotiation and decentralised compute as well as multi session udp establishment (for speed).
The latter part may still use rudp (or Crux rudp2) with the ability to lose frames (for video, voice etc. this is fine) but maintain the connections via the current keep-alive (pseudo tcp connection oriented approach).
So there is work to be done there for sure, but I think when we launch and many more see how we have done what we do then the games programmers etc. will get the aha moment and answer much of this for us.
I thought a lot about this last night, and had an identical line of thought. Once the network is churning some of us will be be able to come up with the solution.
Seeing and working with how the SAFE Network will navigate data.
I’d like to see whitepapers on this, to see how they prevent MiTM attacks. If its typical PKI with their servers as the CA, then no real improvement is seen with this system because you still have to trust their servers entirely. They could also try a ZRTP approach with DH, but the Javascript code would have to generate the keys and display the hashcode - since the server provides the Javascript code each time the page is accessed, nothing is really gained. Also according to Wikipedia, the NSA has been working on voice analysis + synthesis (why not?), which would defeat the ZRTP approach if they could implement it somehow.
ZRTP and PKI systems still have the advantage of keeping some state for verification next time the user is contacted (making MiTM more difficult after first contact), but since this is all browser based, its likely that any state would be stored on the server unencrypted! IMO, you need a pure Javascript front-end that can be downloaded locally (so a user can re-use a known implementation), which downloads user data from the server and decrypts everything locally (like Lastpass). It would be nice if Megachat went this far, but often half-measures are used for security, while the privacy claims are boundless.
What about anonymity in this situation? I thought it would be interesting to have both anonymise chat with known public anonymise identity. Does that make sense to anybody, but me?
@dirvine is talking about VOIP and Video. Chat should be no problem going over let’s say 12 hops. If one hop goes down the message will be routed to the right XOR-address without any problem. For gaming, VOIP and live-video, latency should be low. Quite hard to do while being safe and using hop after hop after hop.
I agree, but this means there are two methods of communicating with PMID. Direct and indirect. Somhow applications will have to relay to the user which is being used.
Absolutely, I think though the direct communications should be encrypted at the network level, but it’s for sure not finalised yet (I am uneasy about insecure for speed type issues and prefer secure). With cpu and b/w increasing so fast then I do not think encrypting even with a fast stream cipher like Sosemanuk would be acceptable (way faster than a udp socket can realistically handle just now).
How about negotiating direct connections person A → random node A → random node B → person B
This way you could videochat with no one party knowing who two people are talking (as long as both nodes are not owned by same entity). Of course the intermediate node count could be specifiable 2…n at the cost of latency to increase security. Even 1 node could be used but then you would have to accept that a third party knows who are chatting, but neither chatter knows.
Of course if the traffic is end to end encrypted then this setup could be used for any communication between two computers without the intermediaries knowing what type of communication it is.
Great idea.For chunks of data there can be a lot of hops in between just like the routing already is, for videochat and VOIP only a small number of hops. I2P does already something like that, they use outgoing hops and incoming hops. I think it was something like 2 proxies out and 2 proxies in. So for this idea it could be something like one hop out and one hop in on the other side.
). This can take a few forms though and in this case I feel we will have to provide network level API’s to allow negotiation and decentralised compute as well as multi session udp establishment (for speed).