Allows library users to replace the underlying listener used by the application

[eyedeekay]

This PR alters the writefreely app in such a way that the behavior is identical to before, but, the Listen function is called separately from the Serve function, and the Listen function is declared as a variable at the top scope, who's value is by default net.Listen. This allows people who are using writefreely to create a replacement for the Listen function which will be called by the app.

Use Cases:

• Easy selfhosted blogging without port-forwarding hassles/risks or VPS expenses
• Listening on Tor or I2P services directly, without listening on other interfaces
• Listening on dweb-type systems such as IPFS
• Automatic discovery of VPNs such as Tailscale

For instance, this file(in my tree as i2p.go but not checked in on this PR) will automatically configure writefreely to listen on I2P, and if it's asked to federate, it will also federate over I2P.

package writefreely

import (
	"net"
	"net/http"
	"strings"

	"github.com/eyedeekay/goSam"
	"github.com/eyedeekay/onramp"
)

func ListenUnixI2P(network, addr string) (net.Listener, error) {
	if network == "unix" {
		return net.Listen(network, addr)
	}
	host := strings.Split(addr, ":")[0]
	if host == "localhost" || host == "127.0.0.1" {
		return net.Listen(network, addr)
	}
	garlic, err := onramp.NewGarlic(addr, "127.0.0.1:7656", onramp.OPT_DEFAULTS)
	if err != nil {
		return nil, err
	}
	return garlic.NewListener(network, addr)
}

var sam *goSam.Client

func init() {
	Listen = ListenUnixI2P
	var err error
	sam, err = goSam.NewDefaultClient()
	if err != nil {
		panic(err)
	}
	http.DefaultClient = &http.Client{
		Transport: &http.Transport{
			Dial:        sam.Dial,
			DialContext: sam.DialContext,
		},
	}
}

This PR is related to #662 however it does not accomodate "multiple" listeners in the same app.

---

• [ X] I have signed the CLA

[thebaer]

I'm getting an error here when trying to compile:

gopher.go:33:9: undefined: gopher.Serve

[thebaer]

Thanks for submitting this! I'd definitely love to support this kind of use case.

My only concern with this is continuing to support multiple listeners, e.g. HTTP and Gopher, like we have now. It looks like this changes that (though I haven't verified -- see review comment). But it's pretty important that we continue making it dead-simple to run multiple protocols from a single instance, for those who want it.

Is there a way we can continue doing that, while also supporting these other use cases?

[eyedeekay]

Yes it should be 100% possible, it's been a while since I looked at this PR, let me refresh my memory and see what I can come up with. I must have something unchecked in for that failed compilation.

[thebaer]

Okay awesome, sounds good!