Non-Monetary Incentives For Joining The Safe Network

NON-MONETARY INCENTIVES FOR JOINING THE SAFE NETWORK

Though what I am about to suggest here I suppose could be classified as “features” or “ideas” or “suggestions” within the realms of the functionality of The Safe Network, I am posting this to marketing because the features I am about to propose really have more to do with motivating people to join The Safe Network and these features really have nothing to do with SafeCoin. Hence why I am listing this as “non-monetary incentives”.

These features would act as a “SAFE NETWORK AWARENESS CAMPAIGN” but it would be completely based in how the infrastructure speaks for itself. None of this is going to be based in any sort of psychological marketing or promotional gimmics, but rather: need, want, supply and demand. Things that are based on the elusively obvious and falls in the category of what in todays crazy world, one might call “not so common, common sense”.

At this point it is understandable as to why The Safe Network is focused on its vault / safecoin system for the expansion of the Network, and rightly so. I do feel however that it will be important to have some features that though they are not necessarily directly having to do with this aspect of The Safe Network, they would provide huge incentive for people to run vaults on the network. Though the SafeCoin CryptoCurrency incentive is nice, there does need to be more incentives in addition to it. Just like any other technology, useful and desired features of a technology act as incentive in and of themselves.

I’m going to describe some specifics of what one might call a VPN-style or PROXY-style Gateway or Passthrough function. A rose by any other name still smells as sweet, so don’t get too hung up on terminology such as “VPN” or “Proxy” because it might risk the mind becoming too literal and focusing too much on what these sorts of things already are and how they already function. The Safe Network is about taking inspiration from what already exists, and making new things that work better. So please do try to remain concept-oriented when reading this post, otherwise if you get too technical in the specifics, some key points might get missed.

TOR & I2P PASSTHROUGH

Though this concept holds true for many other existing secure decentralized networks that should also be included here, I’m going to focus on TOR and I2P as key examples because these networks:

-are already very large and have a lot of nodes
-already have their own addressing systems (*.i2p aka eepsites, *.onion)
-already work in unison with each other (ie: retroshare, etc)
-both have a few small flaws that The Safe Network could easily fix by default of it being what it is

With *.onion sites, you’re only as safe and secure as your exit nodes so despite its decentralization, exit nodes are a centralized point of failure. Though passing onion through I2P using applications such as RetroShare solves that problem: RetroShare is purely application-based (no web) and in order for the encryption to work at all (and RetroShare is entirely dependent upon its encryption for understandable and obvious reasons) your router has to have extremely good UPnP on board, otherwise its just not going to work properly, if at all. Though custom router firmware options such as OpenWRT, DD-WRT, etc do solve the UPnP problem, the other problem is that there are still a great many routers that custom firmware platforms simply will not install to just yet. In the current economy, many people do not have the extra money to spare right now to get a good expensive router that will support this sort of thing.

Another issue with both *.onion and *.i2p sites, is that similarly to any other website, the content does revolve around a centralized web server. So yes though the traffic flowing in and out of the server is decentralized, these sites still require a central computer to host the site. If that central web server goes down, the site goes down. Just like any other regular http website. So this is yet another central point of failure.

Allowing the TOR and I2P Networks to be able to pass through The Safe Network to make them 100% secure for as long as both the entry and exit points are both on The Safe Network, would encourage TOR and I2P nodes to run Safe Network Vaults. It would also be a requirement that they do so, in order for this function to work.

This would also allow TOR and I2P sites to make their sites simultaneously a Safe Network Website and a *.i2p / *.onion website, at the exact same time, through the use of SAFE-VFS. As far as I know, both TOR and I2P websites are just regular HTML sites with no special requirements (ie: they’re not php or asp or cfm, etc and they do not have any special backend requirements other than the TOR / I2P networks themselves) – therefore, I do not personally see any potential functionality conflicts.

Allowing TOR and I2P to pass through The Safe Network would also give The Safe Network Browser the ability to directly access the TOR and I2P Networks directly. To differentiate between the networks, you could use the following syntaxes:

safe://my-website.ext
tor://my-website.onion
i2p://my-website.i2p

The Safe Network, in a sense, would also act as a sort of Secure VPN for TOR because all anyone on the TOR side of things would be able to see, is that the TOR Network was being accessed by The Safe Network, but because The Safe Network protects the identity of all machines during any data exchange, there would be no way for anyone to violate privacy. Where as on the TOR network, exit nodes can be compromised to such an extent that even the TOR Browser warns you that you are suggested to keep the browser the same size on the screen as the size it is when it loads, otherwise your privacy might still become violated.

If the most secure way to run TOR is through I2P, and the absolute most secure way to lock down TOR would be to then take the TOR and I2P Networks and run them through The Safe Network – then browsing *.onion and *.i2p sites would be done 100% securely through The Safe Network, thus providing massive incentive for TOR and I2P Nodes to become Safe Network Vaults. And for TOR and I2P users to browse using the Safe Network Browser.

RetroShare using TOR and I2P would then also no longer need to worry about silly UPnP issues once they create their own plugins to route things through The Safe Network. They would then also be able to store data into The Safe Network and be able to have a website system of their own that co-exists on The Safe Network web, such as for example:

safe://my-website.ext
retroshare://my-website.rs

RetroShare would simply need to create a plugin that is able to communicate with The Safe Network web browser, simple as that.

HTTP & HTTPS TUNNELS AND GATEWAYS

Though having a website simultaneously exist on the regular web and The Safe Network web would have its challenges, that is NOT a concept I am going to be getting into here. This is something else entirely.

Secure VPN Services are getting cheaper because they are getting more popular. They are getting more popular because of the increases in censorship and other forms of harassment that people are receiving from both corporations and government who are becoming increasingly focused on thought-policing the masses. Not to mention terrorism, identity theft, ransomware and other problems.

With HTTP and HTTPS tunneling, being able to use the regular web through The Safe Network would act as a form of secure VPN, because all any “regular web” view of the data transfers would be able to see, is that a whole bunch of ip addresses each pulled tiny little chunks off of a file, sending it straight into The Safe Network itself, with no trail to be able to follow.

This would give incentive for regular web users to switch over to using the safe and secure Safe Network browser, which would then also introduce them to the ever-expanding number of Safe Network websites, as well as other websites on other encrypted decentralized networks that are using The Safe Network as a passthrough (ie: all of the before mentioned about tor, i2p, etc). The more the Safe Network browser gained in popularity, the more it would also incentivise people and corporations who run regular websites, to also establish Safe Network websites and become Safe Network vaults.

The increase in popularity would also draw the interest of third party developers who would also desire to create useful browser plugins, such as what has already been happening with Firefox, Chrome, etc and their wide variety of plugin utilities.

An HTTP / HTTPS Gateway would do the inverse. It would allow regular web users to be able to browse Safe Network websites through the browser they already use, with the usual warning that because they are not a part of the Safe Network, that their privacy is not protected and thusly they are suggested to join The Safe Network. One existing example of this sort of service is: https://www.hiddenservice.net

Hiddenservice.net lets you access both TOR and I2P hidden services / eepSites from your browser.

The most important aspect of this, is that in so doing - regular Internet search engines spider the HiddenService URLs and bring awareness to the general public about the TOR and I2P Networks. Imagine if sites like this could also include The Safe Network web? Imagine sites like this running Safe Network vaults?

In these times where censorship, political correctness and digital attacks have not only become a disease but an outright plague epidemic – these sorts of features are absolutely important to the spread of awareness about The Safe Network and the continued expansion of the network.

So I strongly warn that to not consider features like this could be potentially damning for humanity as a collective whole, as well as The Safe Network itself.

4 Likes

Bear in mind that any exit/proxy/relay vaults will expose their IP address. It may be good for the user to be able to browse with impunity, but it is not good for the vault host who may get black listed, legal threats, etc.

4 Likes

And that isn’t the end of it. By creating bridges you allow any insecurities in those systems access to SAFE. Like you say the IP address of the exit point from SAFE. But then it allows targetting of the Node directly because the IP address is now known. If all nodes are allowed to become various exit points as part of SAFE then an attack can be made to expose the IP addresses of the majority of the networks Nodes to the attacker.And of course a greater surface area for attacks then opens up, they know IP address and code base is much larger giving greater chance of attack.

But lets take a step back and look at what this would mean.

  • SAFE if it does what is on the box, then TOR or P2P will migrate across faster than what you could advertise bridges for. An ordinary browser will suffice till the migration is done.
  • By propping up these relatively insecure systems then you slow down the adoption of SAFE because people will only use SAFE for bridges and thus not using SAFE for its real power. (And less buying resources and use of resources)
  • by exposing the Node’s IP addresses in such an easy manner then blacklisting becomes much easier for companies/governments.
  • peer to peer services will move to a superior system very quickly. six months or less I’d say. Bittorrents will among the first
  • Of course noone will use SAFE for any of these things until its proven safe and secure. Thus no real use of bridges or migrated services will occur till SAFE has proven its not a honeypot and its safe and secure And this defeats any perceived benefits of bridges.

The last point is a real killer for implementing bridges in order to speed up adoption of SAFE. And the point of actually slowing down adoption of SAFE for secure services by providing bridges also is a killer for this idea.

6 Likes

@psecdocumentary

1 Like

Okay then. I guess this means that for things such as tor:// and i2p:// those networks would need to fully migrate to The Safe Network, entirely. So the first thing that would happen is a network split to where software is made that allows for tor and i2p to run within The Safe Network as protocols, and in such a way that they are not able to communicate outside of The Safe Network.

So migration incentive would come from making commonly used protocols and services available inside of The Safe Network, but those inside would have no communication with their sister protocols outside of the network.

If bridges are a no-go, then what about Gateways similar to HiddenService.net? If a site like that was running a Safe Network vault, then all anyone would be able to see is what regular web user is talking to HiddenService, but they would not be able to identify any ip addresses on The Safe Network because HiddenService would be pulling a copy of the content from the Safe Network to a temporary cache directory on its own webspace. So all any governments or corporations would be able to see is that a web user contacted HiddenService.net and requested content of it, and the content was delivered from a directory on its servers.

Or is there a security hole in this that I’m not seeing? As The existence of HiddenService.net compromised Tor and I2p?

Depends on the bridge. Tor will expose the IP address of the Node and therein is the major problem. Also you wanted the Nodes to all have the gateway built in. For anon bright website surfing then Tor is still better than a SAFE with a bridge built in and for hidden tor websites then just migrate the website and not openly advertise the website

Gateways if any will be at the APP level. This means that anyone one can be a bridge if they wish and is not part of the core code. Thus 2 very serious problems are solved. The real question is if the bridge is useful and will it actually delay adoption of SAFE as the network of choice

Also SAFE is Tor on steroids and no need to migrate it. Just use any of the properly written messaging APPs or visit safe sites instead of Tor sites. So the migration for Tor is to migrate the sites to SAFE.

I2P - SAFE again is I2P on steroids since any communications can be totally anonymous on SAFE. Only if the person tells others about the ID used or the communications can the said communications even be known about.

This is why TOR and I2P do not need bridges built into SAFE code since SAFE does these itself much more securely and sufficiently. Basically SAFE will most likely make TOR and I2P obsolete.

6 Likes