Got a new question? File an issue or visit us on IRC2P, and I will add the answer here!
I still get this question alot, and it kind of surprises me at this point. After all, many major clear-web services already have the very similar Tor Hidden Services, and Tor even added a feature called "Single-hop Onions" to help non-anonymous services be more effiecient and accessible to anonymous clients on their overlay network. This is so that you can add value to your service by allowing clients to access it anonymously. Besides that, there are also several services on.i2p which are accessible from clear-web counterparts, services such as Jabber, e-mail, and activitypub-based social-networking.
So the point of the DuckDuckGo hidden service, for example, isn't to anonmymize DuckDuckGo, that's obviously not possible. It is to provice anonymous, blocking resistant access to visitors who do not wish to reveal their possible coarse physical location in the form of their IP address. Moreover, it is actually very easy to allow this kind of access to your existing web service.
Just in case you didn't know,.i2p has fairly few outproxies, all run by volunteers. We really appreciate the work of our outproxy operators, and they have a job that can get pretty complicated providing generic access to the clearweb for anonymous clients. As a web site operator, you are in a genuinely unique position to make this job easier. Only you can safely provide an eepSite for your existing clear-web service to accept anonymous users and only you can reduce the burden on the outproxy operators.
This is the reason your participation in the.i2p network is so essential to providing anonymous access to your eepSite. After all, anyone can set up a fake gateway to say, reddit.com:80(Because somehow Reddit still lets you use a plain HTTP connection in 2019, fortunately, most browsers at this point won't let you use it in practice), as a Tor hidden service or.i2p eepSite and unless your users take the time to verify the .onion or .b32.i2p address manually, they seriously risk typing their password into a malicious site.
The difference you and only you can make is to use your TLS certificate to ensure that the hidden service that the user connects to is the same site, run by the same people, as the clear-web service, the behavior that the user not only expects but absolutely counts on.
Honestly you don't have a choice between allowing, or not allowing, anonymous access to your site. If you block outproxies,.i2p users will simply use Tor. If you block Tor exits, Tor users will chain open HTTP Proxies. If all the open HTTP proxies disappeared overnight(they won't) then VPN's would still be a thing. And, to belabor a point already made by Tor, botnet-based anonymizers used to conceal criminal activity already exist in the wild and are more likely to be used maliciously than Tor, because that's what they're for! So the real choice is
And in light of that, I think the choice is pretty clear. If you want your anonymous users to be like your regular users, you should treat your anonymous users like regular users, after all, that's what they are. :)
Your server may allow the user to trigger interaction with a remote outside of your control. For example, federated applications are able to make requests to other members of their federation, so in open federations it is especially important to ensure that all traffic outgoing from the server is routed to an anonymizing network. Other things to watch out for could be user-supplied avatars or globally-recognizable avatars, which are implemented in many popular pieces of software such as PHPbb, pingbacks from blogs, etc. In some cases, setting the *_PROXY environment variables in the context of the service is enough to route the traffic over the proxy. If this is the case with your server software, then it is also possible to use Privoxy to route server traffic to other.i2p eepSites, Tor Onion Services, and clearnet traffic.
Unfortunately, some software, in my experience much of it is in PHP, doesn't honor these environment variables. I don't have a straightforward solution to this yet, however, a Whonix-based setup or a SOCKSifier may be possible solutions.