
Alexander is a writer, traveler, and serial digital entrepreneur. He’s the founder of the Tushi, the Gen X personal growth newsletter Further, and offers small business advice at Unemployable.

Twitter

Linkedin

Facebook

Director and Chief Evangelist

Alexander Hipp


Anil is a content-obsessed marketer who loves driving organic traffic for outstanding companies. He is also the creator of Hack the Content, co-host of The Runner, and owner of several digital commerce sites.

Managing Partner

Anil Vugels


Monika is a writer, musician, and content strategist with a passion for language. When she isn’t helping clients, you can find her writing songs, hiking in a northern forest, or furiously journaling.

Director of Operations

Ann Monika

Mastodon

Github

Programmer / Founder / Student

Tim Schupp


Beginning of this year during studies of a course at University taking a course on communication systems;
I had an Idea for a Topic - or actually the idea formed for a while before - but during that time I found the motivation to craft it into a proposal.

Ultimately this didn't come to fruition - yet? - as I'd still be interested in building and testing this or a similar protocol;
or also in general learning more about p2p protocols and communication systems; also their performance and limitations in practice.

Anyways what was this 'idea' about and how did it form?
As I was learning go lang or maybe even some time before when I was playing with messengers; learning about encryption and things;
or maybe even Waaaaaay before; When I was 14 I built [this little RSA calculator app]() which only remaining archive reference is that old archive link here.

Whats my point? Yeah I was interested in encryption, privacy, decentralized systems, torrents, peer to peer - anything in that space, for a while; crypto-coin related stuff not so much - some of the blockchain use cases and technologies were still interesting to me - in a sense which technical capabilities they provide.

So some day when I was exploring to learn golang - prob a decision in one of my many ventures in building realtime chat apps - I ended up stumbling upon [libp2p]().
Very intrigued by the idea or a having a well crafted; clear protocol, that can be implemented in several languages and solve a stack of challenges in communication systems with focus on p2p.

### Initial experiments

Originally the federation experiments [were directly built into open-chat ( as a golang lib & git-submodule) ](https://github.com/msgmate-io/open-chat-go-federation)

Open-chat is my [Open-Source llm automation tool-kit](https://github.com/msgmate-io/open-chat-go) - but in the proposal I aimed to cleanly separate and re-write its implementation short protocol definition on top of libp2p that would allow easy seamless peer to peer networks / communication hopefully fulfilling the following requirements I chose:

1. is an application layer protocol, based on libp2p
2. same logic on every node, no central control node
3. automatic peer discovery and address management
4. multi network system with authentication based network join procedure
5. fully separated per-node and per-network access control and configuration
6. ability to exclude a malicious peer from a network
7. is as simple as possible while maintaining (1-6)

Loosely these were also the original thoughts when I started building it into 'open-chat' as an 'federation' implementation.
I've published all the 'unclean' early experimentation code [now here in this repo](https://github.com/msgmate-io/open-chat-go-federation).

In the proposal I sketed out a re-desin of that protocl and a-reimplementation relying on 4 basic data structures and 7 different api endpoints.

The minimal system desined for this Thesis would require at-least the development of these APIs:
- `GET /peer_info`: Endpoint to access node id peer information
- `GET /get_federation_node/<peer-id>/` retrieves node info of a federation member
- `POST /relay_network_request/<network>/<peer-id>/` sends a HTTP requests into the network
- `POST /register_network_peer/<network>/<peer-id>/` tries to register a network peer
- `POST /authorize/`: Used for user / network authorization
- `POST /synchronize_network/`: Synchronized Peer state for authorized network users
- `POST /add_route_rule/`: Allows defining VPN / routing rules. This is what creates and

manages network (tun) devices and proxies routing rules across nodes
Each node needs some basic data structures for:

- Users ( Admin and Network Users, hold authorization information )
- Networks ( Registered Networks )
- Peers ( libp2p manages an internal peer table, that is not persisted across restarts )
- Routing Rules ( Hold per-node information for VPN routing )

The approach this differs significantly from the proposal as it requires multiple additional models and logic to function.
Yet it was fully functional and reliable in my initial experiments and experimental deployment; [e.g.: as I described in this blog post a while ago](https://blog.t1m.me/blog/breaking-through-nat).

### The Proposal

Here you can read the original proposal as it was handed in - and prob read maybe once.
I censored the receiver name and the course and anything related to the people involved except my own name.

<iframe
  src="/static/assets/proposal.pdf#view=FitH"
  title="Master thesis proposal PDF"
  style="width:100%;height:70vh;border:1px solid #d9d9d9;border-radius:8px;"
></iframe>

[Open the proposal in a new tab](/static/assets/proposal.pdf)


Anyways time is scarce and working full time and trying to do any courses at-all has taken all the Energy I had so far;
So writing this post is for now shall be the 'ticket' to continue here some time.

### Outlook ?!

Yeah still like the idea; prob its horribly hard to get right and way more complicated than I imagine - quite a things I'd like to bite a thought out on though.
So given the time and opportunity I'd love to build and test such a thing even better in a Scientific context.

So maybe I shared this post with you for context; or you found it somehow
-> in any case if you are interested in helping out or have an Idea where I could hand in another proposal attemt


> then let me know: `tim+libp2p-vpn@timschupp.de`


Attempt at creating my own Master Thesis Topic

A Botched Master Thesis Proposal and My Idea for a Decentralized VPN


[Open-Chat](https://github.com/msgmate-io/open-chat-go) is not in it's 7th iteration and fully re-written in golang.
It now as 'federation' features using libp2p, it allows you to quickly spin-up your own network of open-chat nodes.

Open-Chat network member can freely communicate with another, they are automatically joined into a completely independent self-healing overlay-network.

### Creating a Open-Chat Network

Open-Chat Networks can be established inside private networks, across public networks *or across both*.
To be able to penetrate across public and private networks open-chat need to be able to route traffic back to itself trough a router, 
or it need to have at-least one public relay peer available to use as alternate path.

#### **1. Prepare a Bootstrap and Relay Node**
On our public node, we want to use as 'relay' and 'bootstrap' peer, download the Open-Chat binary [from the github release page](https://github.com/msgmate-io/open-chat-go/releases)
Be sure to download the one with '-federation' build in.
E.g.: 

```bash
wget -O open-chat https://github.com/msgmate-io/open-chat-go/releases/download/build-10/open-chat-federation-0.0.111-linux-amd64
chmod +x open-chat # make it executable
```

#### **2. Start first federation node**

For the 'bootstrapper' node you'll have to specify base admin credentials and network-credentials
- network credentials allow 'read-only' network operations and are required to be known for joining a network
- admin credentials are individual to each node, they are required to perform any elevated privilege action, e.g.: creating proxy routes

All can simply be specified like this:

```bash
./open-chat --default-network-credentials "<network-name>:<password>" --root-credentials "<user>:<password>"
```

You can also initalize not credentials without revealing them by specifying `--root-credentials "<username>:hashed_<pdf-hashed-password>"`.
Now that our bootstrapper node is available we can use its peer-id to bootstrap other nodes.

> If you want to persis your open-chat configuration system wide just run it with `--install`

We can extract it's peer Id by either loggin in to the UI with the admin user, or via the Open-Chat cli:

```bash
./open-chat client login                # you'll be promted to ender username and password
./open-chat client identity -b64        # revals the node id in a re-usable base64 format
eyJpZCI6ICI8TE9DQUxfUEVFUl9JRD4iLCAiY29ubmVjdF9tdWx0aWFkcmVzcyI6IFsiL2lwNC88U09NRV9JUF9BRFJFU1M+L3RjcC8wL3AycC88TE9DQUxfUEVFUl9JRD4iXX0=
```

#### **3. Adding other nodes to the network**

The only thing you need is the bootstrap peer string and the networks credentials

```bash
./open-chat -dnc "<network-name>:<password>" -rc "<different-node-specific-admin-creds>" -bs "<base64-bootstrap-peer-string>"
```

Now we just need to wait a moment untill these nodes found each other and established connections.
Lets see if the nodes are connected.

```bash
./open-chat client login          # ....
./open-chat client nodes -ls    # list all available nodes
```

Now lets *see if we can send requests to the node*:

```bash
./open-chat client get-metrics --node <remote-peer-id>
```

Hurray it works! **Now where do we go from here?**

#### **4. Establish on-demand proxy routing rules**

When we have a network, we can model its traffic in any-way we like.
Open-chat nodes can configure arbitrary routing rules on per-node basis, 
every node can only route traffic that goes trough itself.

To route traffic trough another node, routing rules on that node need to be established, 
thus the admin credentials for that node must be known.

Since we control the full network we know admin credentials of very node and can establish any routing rules we want.

**Lets use open-chat to create a ngrok-like TLS to behind NAT reverse-proxy**, to achieve this we need:
1. A single public peer in our control with an `<PUBLIC-IP>`
2. A domain name A-Record pointing that IP `<HOSTNAME>`
3. A private behind NAT node that hosts some TCP service on `<peer-port>`

> All the steps presented here can also be run from a single node, by using network-requests that are build in to Open-Chat.
> For simplicity we run command on individual nodes, but there are also workflows that allow controlling routing rule requests to ANY node just from a single network member.

##### 1. Use open-chat to request TLS certificate on the public node

```bash
./open-chat client tls --hostname "<HOSTNAME>" --key-prefix "<self-defined-certificate-prefix>"
```
This will automatically start the ACME challenge process and saves the obtained certificate in the Open-Chat nodes database.

##### 2. Establish TLS to network routing rules

First we need to tell the public node to accept TLS traffic using the just obtained certificate.
It should only accept traffic coming from `"<HOSTNAME>"` and the traffic should be routed to a specific port on the system.

```bash
./open-chat client proxy --direction "egress" --traffic-origin "<HOSTNAME>" --traffic-target "<key-prefix>:<peer-port>" --kind "tls" --key-prefix "<self-defined-certificate-prefix>"
```

This create an 'egress' proxy that accepts incoming traffic from the `"<HOSTNAME>"` and runnels it into the network.

```bash
./open-chat client proxy --direction "egress" --traffic-origin "<own-peer-id>:<peer-port>" --traffic-target "<remote-peer-id>:<peer-port>" --kind tcp
```

This establishes an 'ingress' rule from the network to the remote peer node.
Now the only thing that is left to do is the local node to tunnel network traffic from that peer to the `<peer-port>` that runs the TCP service.

##### 3. Accept Network Traffic on a local Port

Traffic is now routes from the domain to the public peer, from there inside the network and to the remote peer.
But currently the remote peer would just drop the traffic as it doesn't know what to do with it, lets route it to the port that runs our service:

```bash
./open-chat client proxy --direction "ingress" --traffic-origin "<own-peer-id>:<peer-port>" --traffic-target "<remote-peer-id>:<peer-port>" --kind tcp
```


### Conclusion and Outlook

**This Article merely gives a hint what Open-Chat Federation is able to do**, options from there go way further.
Just as food for though, the following thins are only a few lines of open-chat rules away:

1. **Decentralized Multi-Site behind NAT hosting**
Host a swarm of Server behind NAT on different locations, route them trough multiple public peers in a 'load balancing' fashion
and you have a load resilient decentralized server infrastructure that masks the actual server locations, allows for easy traffic filtering and allows for easy horizontal scaling by just extending the node pool.
2. **Persistent self hosted Ngrok**. As shown in this article open-chat can easily be used to create development routing rules as tools like ngrok can do.
3. **Self managed overlay networks for anything**. This connect extends to any application, also the ones fully privately easily use open-chat routing rules to manage traffic in your local network, *you may even use it in offline local networks!*.


How Open-Chats Federation Enables anybody to host anything anywhere

Open Chat

A Botched Master Thesis Proposal and My Idea for a Decentralized VPN

Breaking Trough NAT: Decentralized Self-Hosting Via Open-Chat