Proxy for resolving and accessing websites over dmsg with a web browser

[0pcom]

Currently, a functional framework exists for having websites over dmsg (dmsghttp)

However; there is a challenge posed on the client-side for accessing these websites via existing browsers.

I had looked at the idea of a custom URL scheme or protocol such as dmsghttp:// or dmsg:// ; however this is something which has severe limitations in terms of browser support currently.

A custom protocol or url scheme would need to be supported by the browser upstream, basically. Which is a non-starter.

Previous efforts

I have previously taken steps to make a client which runs on localhost proxy websites which are fetched over dmsg (with dmsgget).

The downside with such an approach is that it breaks all the links ; on-page navigation and cross-site navigation. With such an approach, websites would need to be specifically written (or rewritten) with relative links prepended with the : of the web site or service running over dmsg.

i2p's approach to the problem

https://i2pd.readthedocs.io/en/latest/tutorials/http/

After some research and experimenting with i2p (i2pd), it appears that they achieve the goal of browse-able websites in the following way:

Upon configuration and running of i2pd, a proxy is exposed at 127.0.0.1:4444 by default.

When this proxy is configured in a web browser, it does not appear to force all the traffic through the proxy connection for non .i2p websites, in other words, normal web browsing is unaffected.

However, this proxy enables resolution of i2p domains and displays them in the browser if they are found.

This seems like a good approach for achieving the desired functionality of p2p websites over dmsg for skywire.

Websites over dmsg are not websites over skywire

Websites over dmsg may be in a sense anonymous, however the traffic is directly p2p and does not take advantage of routes over skywire.

To take advantage of routes, the framework for websites over skywire would need to integrate in some way with skyfwd which does use transports / routes.

Even if a multi-hop route was used to access the website, web application, or service over skywire, there is not currently a way to enforce on the server side that a website or service may only be accessed via a route with more than one hop.

[0pcom]

Partial Implementation

package main

import (
	"context"
	"fmt"
	"log"
	"net"
	"net/http"
	"strings"

	"github.com/armon/go-socks5"
)

type customResolver struct{}

func (r *customResolver) Resolve(ctx context.Context, name string) (context.Context, net.IP, error) {
	// Handle custom name resolution for .dmsg domains
	if strings.HasSuffix(name, ".dmsg") {
		// Resolve .dmsg domains to the desired IP address
		ip := net.ParseIP("127.0.0.1") // Replace with your desired IP address
		if ip == nil {
			return ctx, nil, fmt.Errorf("failed to parse IP address for .dmsg domain")
		}
		return ctx, ip, nil
	}

	// Use default name resolution for other domains
	return ctx, nil, nil
}

func main() {
	// Create a SOCKS5 server with custom name resolution
	conf := &socks5.Config{
		Resolver: &customResolver{},
		Dial: func(ctx context.Context, network, addr string) (net.Conn, error) {
			fmt.Println(addr)
			return net.Dial(network, addr)
		},
	}

	// Create a custom HTTP handler for .dmsg domains
	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		w.Write([]byte("Hello, World!"))
	})


	// Start the SOCKS5 server
	addr := "127.0.0.1:1080"
	log.Printf("SOCKS5 proxy server started on %s", addr)

	server, err := socks5.New(conf)
	if err != nil {
		log.Fatalf("failed to create SOCKS5 server: %v", err)
	}

	err = server.ListenAndServe("tcp", addr)
	if err != nil {
		log.Fatalf("failed to start SOCKS5 server: %v", err)
	}
}

with caddy running in the default way

[0pcom]

I've had some additional thoughts / insights about websites over skywire.

There are certain advantages to websites over dmsg vs websites over skywire using the current implementation of skyfwd.

The primary advantage is that dmsg is slightly more reliable than skywire routes currently.

Another thing to consider, if a proxy for accessing websites over skywire was implemented as the proxy for accessing websites over dmsg, certain steps would be required to avoid unmasking the ip address of the visor, such as the strict use of the dmsghttp-config and disabling, perhaps even manually removing certain services which are configured for the visor so that sudph and stcp/stcpr transports could not be created, only dmsg transports.

Then, a stroke of insight. It's likely the wrong approach to add the capacity for websites over skywire directly to the visor or to further extend skyfwd because the visor is inherently connecting to many different services using it's public key, which is the same key that would be used to access the website or web application with skyrev ; however it should be possible to use a running visor to proxify or otherwise wrap a dmsghttp server in the socks5 proxy or VPN connection; which would mean that the dmsghttp server (which is a dmsg client) could connect to the dmsg-discovery & dmsg servers via a skywire route, which could even be a multi-hop route if desired.

[0pcom]

this was implemented as dmsgweb in skycoin/dmsg