All along we’ve spoken loosely about “paying safecoin to store data on the network.”
While this is sort of true, I think that by phrasing it that way we’re missing something about how to think about the network dynamics and the likely behavior of safecoin.
The resource that the end user pays for, in safecoin, is the ability to PUT data to the network. The term “store” is technically correct in a way, but it implies that the data will necessarily be kept on the network for a notable, even historic, length of time. I’m now doubting whether that’s how even a majority of PUTs will end up.
Vaults have the opportunity to earn safecoin from the network by fulfilling GET requests.
I’m thinking that a pretty high percentage of PUTs and GETs will be of fairly transient data that won’t hang around for real long.
A couple of questions this brings up for me are:
Do PUTs for email, messaging, voip, video conferencing, etc., also result in GETs for which vaults will have a chance at farming safecoin? Or are farming opportunities available only on data stored less transiently?
The SAFE network will function a bit differently, but does anyone have any raw data about how current internet traffic breaks down in terms of data that is pretty transient and data that is stored for a longer period? (Ignoring for the moment that NSA and others Hoover up everything and tend to keep it forever.)
I may just be on a tangent, but it seems that there is a kernel of insight here that is worth seeking.
The way i see it, any communication that is not direct, like email, needs to be stored somewhere so they would require to pay for PUT and farmer would get paid on GET.
For direct communication like voip, video conference, chat, etc. The network can be use just to create the initial peer to peer connection but from there the communication can, and probably should, be off the network. So you wouldn’t pay on PUT and the farmers wouldn’t get any new data.
Yes this data passes through, so no farming reward. If the message contains a file (a datamap really) then the sender has paid to store that.
A while back we did some studies close to 90% of data is only accessed for 30 mins and never opened again. In saying that much is kept as records, but we are terrible at hoarding invaluable data as a race so far.
IN SAFE these will archive, I debate with some of the guys as archive data can sometimes die and why not, but then again it may contain nuggets (if we can read it).
Important point. Public data therefore might have a non-zero value to the network. Private (not public-readable) may be valuable only to the owner.
Clearly private should be charged (per year * capacity) and public could be left alone if it’s accessed (to what extent? To the extent that it covers the basic cost which can be derived from the network?).
Inactive public data may be valuable, too. But if it’s not paid for (to the miners), then it’s not worth the cost.
@fergish, there will be novel ways to use the network.
For example, “pull” mail would work the opposite to today’s push mail.
And since the sender would be the owner, he could delete emails he finds worthless.
does the “proof-of-resource” test also check if nodes are routing these transient data? I am asking because maybe some people would decide to not route them, because they can not earn anything… the TOR network suffers from the lack of incentives, but I am not sure if it’s only the exit nodes.
No docs yet, just scattered around in sentental docs and the like. We will introduce archive types after launch to clean up data that’s not accessed so much. Its a management issue we can reduce for the network if it’s not coping with unread data so often.
Well yes and no. You might lose anonymity but you can still have a very secure connection. If low latency is very important for your app there’s nothing wrong there. We’ll probably see a lot of app that only use the network to start a p2p connection and handle everything from there. It really depends on what you are trying to do. You don’t need to do absolutely everything through the network.
I concerned that any IP based to IP based links create aopportunity for interception, encrypted or not, which SAFE had been designed to mitigate.
I’m not expert enough to say for sure, or exactly how, but it can be hard to be sure you are talking to the IP you think you are etc over the existing internet. Certainly it could be blocked. Certainly it isn’t anonymous. And I suspect it makes it easier to intercept, not least because having identified who you talk to, they can be targeted with malware even if you keep your end clean.
With SAFE, one end only might be known, but if both ends are known I am concerned that is a weakness that could be exploited.
It depends what you need. Do you need military grade security for your diplomats or a good enough security to tell your grandma about the last marvel of your kids? App developer will use the tech they need for their use cases. Full security: go through the Safe network for everything. Good enough security: establish secure channel on Safe then just connect directly.
About the original question, I think using the messaging API through the network won’t cost anything since we aren’t putting data to store just sending data to someone else. I might be wrong but I’m pretty sure I saw that somewhere.
If you tunnel via the network, you wouldn’t expose the connection though. I think both are possible and have different use cases, but I can’t remember where I read it.
Peer to peer encrypted VoIP has a lot of advantages
There is no central server, so there is no central point of intercept
It is encrypted, so interception doesn’t help, since the encryption is strong.
Using the public key encryption, it also assures that you’re actually talking to the person you thought you were talking to.
It is fast, with minimal latency introduced by the network and encryption/decryption.
As for Disadvantages, I would say it has only two
Leaks information as to who is talking to whom, and when.
Is vulnerable to filtering, where IP address ranges are filtered, such as at some country’s border firewall.
I have grave doubts that you would be happy with the voice quality of VoIP routed through the maidsafe network. There’s way too many hops.
If I had to do voice communication through maidsafe, I would make a half-duplex “CB Radio” app, where I push a button to talk, and when I release that button, an mp3 file is created, and sent and then played at the other end. This would give you a worse experience than a telephone call but at least the communication that did occur could be understood without massive jitter and distortion caused by variable network delays…
Otherwise, for most people, I think peer to peer encrypted VoIP provides quite a lot of security.
As I was saying earlier, CPU/Bandwidth for communications that don’t require storage is useful. I.e. use as encrypted tunnel. Comms that don’t require storage only forwarding should not require any safecoin in my opinion. What is the purpose of an encrypted, decentralized, anonymous etc network if your communications can be cut for lack of coin? Communications should be free, but reward the one who is providing the CPU/bandwidth in transit. Mobile phones don’t have the space or bandwidth to be able to serve content or be used for the storage features of the network. It should be free to be able to video/voice over a phone to phone type of connect.
This simply isn’t true. There is a major difference - no CA is required to validate the authenticity of the public keys of the two users. Currently the only way (that I am aware of) of authenticating another user WITHOUT a CA or cumbersome “web-of-trust” involves voice authentication - one party reads the result of a DH (or similar) exchange shown to the them, and the other party validates that the users voice read the exact phrase shown to them. This relies on recognition of a persons voice, and that the users actually go through with the process (I suspect many won’t). This isn’t possible with text since its easy to forge/relay. Depending on your level of paranoia, governments have the ability to forge a specific voice too.
SAFE will hopefully allow for public key authentication without a CA. You could even start an audio chat with someone you’ve only seen post via a public documents, and know that its encrypted end-to-end.
The problem that you’ve identified is an information leakage issue. Someone monitoring connections could create a graph of IPs that connect to each for direct communication. I brought this up elsewhere on the forum, but as David pointed out, the alternative creates latencies making real-time audio/video difficult. I don’t recall any plans for realtime vs non-realtime, but maybe it should be considered. Text/chat/email messages could be forwarded through the network like with other requests, since a sub-second round-trip wouldn’t be necessary for these applications.
Interception can happen even if its routed through normal means - any point in the network in fact. Or were you referring to the information leakage I described above? I know Prakash mentioned forward secrecy to me at some point, so hopefully the direct communication still uses that, which would make interception + cracking more difficult.
Or maybe the concern was about an IP be given to a third party upon request? I don’t know enough about the details of the messaging system yet to respond to this (I believe the implementation has actually stalled right now).
Also keep in mind the idea was always to have separate public and messaging personas. You could prove to certain users that you were both, but theres no reason for anybody else to know. This doesn’t solve the IP mapping issues in direct communication, but it does make certain associations more difficult.
Oh! Also if designed correctly, it could be difficult to know whether each endpoint was communicating directly, or as part of normal SAFE peers. This would break-down over time; IPs frequently communicating with each other are likely to be directly communicating. But anyone taking a snapshot of a short time frame should have a difficult time.
