zrok VS p2pd

zrok - Aims for effortless sharing both publicly and privately. Supports multiple types of resources, including HTTP endpoints and files. Built on OpenZiti (see overlay section below). Apache 2 License. Written in Go.

I'm the lead developer on an open source product called zrok (https://github.com/openziti/zrok). zrok is a peer-to-peer sharing tool for network and file-based resources, similar to tools like ngrok.

fwiw, its back up. stars for zrok and ziti (i.e., the parent repo) are super appreciated!

Tailscale makes outbound connections so it circumvents the need for IPv6 with things like CGNAT.

OP, why not use an open source equivalent to Tailscale Funnel? For example, I work on the OpenZiti project and we created zrok.io which is fully open source alternative - https://github.com/openziti/zrok.

Here's a Dockerfile from the zrok repo you might find helpful: https://github.com/openziti/zrok/blob/main/docker/images/zrok/Dockerfile

I've started with a RPi 1 Model B rev 2 (armv61) running dietpi, which should be fine for Pihole but I'm also thinking of using it to run software to control remote access to my server, which could be Tailscale or Wireguard but zrok looks interesting. Unfortunately that doesn't have a armv61 version, only armv7 Releases · openziti/zrok (github.com) so I couldn't run it on this RPi.

I work on the open source OpenZiti project. We recently released zrok (https://zrok.io/), we have Local Debugging Interface in the backlog - https://github.com/openziti/zrok/issues/73.

Hello, I'm a senior engineer and researcher looking for a cool role. I have 10 years of experience but I've been writing software as a hobby even before that. My background is in FinTech / Ledger technology where I created one of the first 'decentralised' exchanges (for 'altcoins.') I did very early work on 'smart contracts' exploring ways to securely move crypto-assets and handle them. I was one of the first people to utilise smart contracts for anything practical at a time when Ethereum didn't exist yet. I have made small contributions to the design of cross-chain contracts and micro-payment channels.

I have spent a lot of time thinking about the role of trust within contracts and ways to minimalism it. I am also interested in cross-ledger compatibility, and secure crypto-asset storage. I have designed new smart contracts that improve how crypto-assets can be stored, helping to mitigate theft, and contracts that enable advanced smart contracts to occur on ledgers that only have simple transaction capability.

In terms of 'dapps': I have built many trading systems. They cover CFDs, margin, alt-coins, and tokens on various blockchains. I am also interested in p2p networking and spent 2022 building a new stack from scratch. It's a good way to measure my engineering skills and problem solving so here are the links to that:

https://github.com/robertsdotpm/p2pd

It says it uses an over-lay network? If the topology is just like:

peer A <---> overlay (server N ...) <---> Peer B

And your design is to try get packets between the peers then this is going to be very slow. They will have to go via the routes on the overlay network which may have multiple virtual hops to reach their destination. This is a massive increase in round trip time. I'm not sure if I understand the solution right though as I took a brief look. But I don't see how this solves port forwarding or NAT issues as the actual instances still need to be publicly reachable.

I wrote a library for peer-to-peer networking recently and unlike libraries like Libp2p -- my emphasis was on getting direct connectivity to work between peers. I'm not using an overlay for this. I use a range of techniques [direct cons, reverse con, tcp hole punching, TURN] to make the connections happens. With some minor signalling traffic happening over public MQTT servers.

My software is at https://github.com/robertsdotpm/p2pd if anyone finds it interesting. Sorry for the shameless self-plug but I figure it is related. We're both free open source projects. I don't provide a tunnelling solution but you could easily build something like ngrok with this software without relying on proxying as the primary solution. Currently the software has no way to easily get another peers 'address' so using this will need to solve that problem. But a simple key-value store would be enough tbh. Going to improve usability when I next have time.

And the project is on Pypi https://pypi.org/project/p2pd/ and Github https://github.com/robertsdotpm/p2pd