Using Threefold to Create a local Wireless Internet Provider Service

In pursuit of learning everything I can about how to best develop the Threefold Project I have discovered another project using similar technology to do some cool things and I think that their work could be beneficial to the project so id like to open a discussion about the possibilities this project brings to light regarding the threefold grid and the planetary network. This project is located here in the united states and is not involved in the cryptocurrency landscape. The project is called Massachusetts mesh and they are utilizing vanilla Yggdrasil clients to redistribute internet as a local WISP. You can find some information about their project here
https://massmesh.org/


the basic breakdown of what this project proves is possible is that the planetary client could be used to allow 3nodes to provide internet connections to devices outside of those owned by the 3nodes owner over wireless networking. This functions by having a wireless network interface that is bridged into the Yggdrasil interface, then the end users connecting to the wireless network and peering their client to the server on the wireless network. This avoid all of the typical configuration requirements and can even be done with a 3node that does not have a public address, from my understanding, you can direct the end user client to peer with the server across the private subnet of the wireless interface and still receive a functional connection. I still need to test that part though so lets assume a gateway is needed for now as anyone doing this would definitely probably also be running gateways.
This opens up 2 significant possibilities

1.) People being able to attach to an unsecured wireless network and be greeted by a landing page similar to what you would see in a hotel that instructs them how to download the planetary client. In this scenario someone could also require payment to gain access to the internet weather that be in TFT or FIAT.
-The node could have a vm with a file server hosting a planetary client installer for each OS, pre configured with a peer address of the nodes Yggdrasil client, then expose that vm to wireless networks private subnet accessible from the landing page.
- I’m not sure how one would Handle the paywall, but, I imagine it could be unlocked by opening the bridge between ygg and the wireless private subnet
2.) Intra node direct communication could be possible if another 3node has access to the wireless network, Allowing that node to supply the internet connection to its neighbor over the wireless network in time of node failure meaning that nodes planetary connection could endure an isp outage.

I am going to be setting up a test lab early this week to demonstrate/test these concepts and would love any input anyone may have on ideas for usage/implementation for something like this.

3 Likes

I do have couple extra layers of idea that may possibly start some thought, this is gonna face a couple major challenges for adoption

  1. ensuring the security of data passing through the network

  2. handling the workload of supporting multiple clients planetary traffic being decrypted as it exits the network to the outside internet.

My idea for this a subset of nodes with the addition of a piece of hardware,

This is a newer device class that could provide extremely interesting capabilities with zos integration.

The long and short is it’s a enterprise router strapped to a pcie interface with 2x external sfp28 interfaces that can be configured from within the os, and the interfaces of the host are exposed to the router.

This device would be Capable off supporting 3+ gigabits of planetary client tunnel traffic being processed and egressed from planetary to the internet per node with supporting connection.

But I think it could go further, if the planetary interface is created by the os, this device may be able to create an independent bridge to the to it from the outside internet.

This would allow one of these devices to be installed and be configured with variable inputs by zos, to be the providing device of this function under another public IP in the farm. leaving the 3nodes os resources only handling the primary network load and ensuring the end user have minimal hops to internet, without exposing the intermediary network,

Beyond that microtik has switches/access points that could be configured autonomously when connected to this device. I wish I could afford the cart I built!

Propose you built a node with
8c/32g/1tb, on board 10g nics, then this card. As your threefold wisp host.

Then when “deploying” the service on the three node as a vm, this card and a publically accessible address is a requirement.

You deploy the service from playground, then it’s setup for the second sfp+28 to link to a breakout switch feeding external access points.

Because the node router can see network interfaces the node can create a vm with a private subnet address facing the switches/APS running the nessecary file access servers for the devices to review firmware updates, configuration changes etc.

With the link running on a public IP address the configurations will be both predictable and replicable with consistent equipment as you would only need to configure internet->planetary->wireless mesh network.