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.
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.
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.