Figure out a good NAT traversal solution #135

zkat commented 2025年10月22日 22:01:31 +02:00

We've floated the idea of people being able to host on tiny little SBCs right at home as their personal stalls.

But then there's NAT.

Is it possible for us to have a "good" NAT traversal solution here that would let us distribute little personal machines to people? Is there a way to do so without endangering their whole network?

We've floated the idea of people being able to host on tiny little SBCs right at home as their personal stalls. But then there's NAT. Is it possible for us to have a "good" NAT traversal solution here that would let us distribute little personal machines to people? Is there a way to do so without endangering their whole network?

AstraLuma commented 2025年10月22日 22:16:21 +02:00

Ok, so, the problem is that CGNAT and double NAT exist, so a TCP port forward all the way out to the public internet isn't a thing. (I think there's also people that don't have home WiFi, just cellular, but they might not be the target audience for this feature.)

STUN/TUN for game/RTC applications is relatively reliable I think. And it's been used successfully in networking (eg, Tailscale does STUN for NAT punching).

So for maximum compatibility, you need cloud-based entrypoints, and something not entirely unlike a VPN, and devices are now online.

As for security, that depends entirely on how much you trust the security of the appliance.

Ok, so, the problem is that CGNAT and double NAT exist, so a TCP port forward all the way out to the public internet isn't a thing. (I think there's also people that don't have home WiFi, just cellular, but they might not be the target audience for this feature.) STUN/TUN for game/RTC applications is relatively reliable I think. And it's been used successfully in networking (eg, Tailscale does STUN for NAT punching). So for maximum compatibility, you need cloud-based entrypoints, and something not entirely unlike a VPN, and devices are now online. As for security, that depends entirely on how much you trust the security of the appliance.

AstraLuma commented 2025年10月22日 22:17:43 +02:00

I know ngrok does this. The easy answer might be integrate with them and tell customers to pay them. (Although 20ドル/mo is like 4x what I'd want to charge for this kind of ingress.)

I know ngrok does this. The easy answer might be integrate with them and tell customers to pay them. (Although 20ドル/mo is like 4x what I'd want to charge for this kind of ingress.)

MultisampledNight commented 2025年10月22日 23:48:31 +02:00

The cloud-based/public-facing entrypoints could forward to the SBCs at home via Tor, too, to avoid compromising the identity of the store. This would circumvent the problem of NAT entirely. (Whether or not that is desirable is another question)
Setup would be: SBC runs tor in non-relay client mode with a hidden service. Entrypoint runs tor in client mode, possibly also as relay.

The cloud-based/public-facing entrypoints could forward to the SBCs at home via Tor, too, to avoid compromising the identity of the store. This would circumvent the problem of NAT entirely. (Whether or not that is desirable is another question) Setup would be: SBC runs tor in non-relay client mode with a hidden service. Entrypoint runs tor in client mode, possibly also as relay.

zkat commented 2025年10月23日 00:06:48 +02:00

It’s worth noting in this conversation: whatever gets implemented would require a web browser to connect to a public ip address on port 443, and end up in the final server

It’s worth noting in this conversation: whatever gets implemented would require a web browser to connect to a public ip address on port 443, and end up in the final server

vriska commented 2025年10月23日 00:17:13 +02:00

It’s worth noting in this conversation: whatever gets implemented would require a web browser to connect to a public ip address on port 443, and end up in the final server

NAT traversal is, broadly, a technique possible to implement when designing a UDP protocol. It's definitely not possible for standard HTTPS (at least not without exploiting router vulnerabilities, which is obviously not useful here).

With manual port-forwarding, this will be technically possible on most ISPs without CGNAT. I do not think this will be possible to automate: UPnP is much less common than it used to be, and just about no modern implementations allow ports under 1024 (even for IPv6 where this is less of a technical issue).

A centralized proxy service similar to Cloudflare Tunnel is possible, where the server and client both make standard outbound connections to the globally-routable proxy service. Another option could be centralized hosting for the frontend, and talking to the backend over WebRTC. There would be a number of implementation challenges here, but it seems theoretically doable? I'm not really sure it's worth the engineering effort, though.

> It’s worth noting in this conversation: whatever gets implemented would require a web browser to connect to a public ip address on port 443, and end up in the final server NAT traversal is, broadly, a technique possible to implement when designing a UDP protocol. It's definitely not possible for standard HTTPS (at least not without exploiting router vulnerabilities, which is obviously not useful here). With manual port-forwarding, this will be technically possible on most ISPs without CGNAT. I do not think this will be possible to automate: UPnP is much less common than it used to be, and just about no modern implementations allow ports under 1024 (even for IPv6 where this is less of a technical issue). A centralized proxy service similar to Cloudflare Tunnel is possible, where the server and client both make standard outbound connections to the globally-routable proxy service. Another option could be centralized hosting for the *frontend*, and talking to the backend over WebRTC. There would be a number of implementation challenges here, but it seems theoretically doable? I'm not really sure it's worth the engineering effort, though.

vriska commented 2025年10月23日 00:19:15 +02:00

I can think of precedent for the WebRTC approach I mentioned, actually. I believe this is how UniFi gateways handle remote management.

I can think of precedent for the WebRTC approach I mentioned, actually. I believe this is how UniFi gateways handle remote management.

zkat commented 2025年10月23日 00:31:06 +02:00

So we're a pretty bog-standard server-side-rendered MPA, and a lot of the motivation for this is power-shifting and creating more independence, as well as shifting expenses from monthly-and-perpetual to one-time-cost, self-owned, self-hosted.

How would WebRTC fit into that?

So we're a pretty bog-standard server-side-rendered MPA, and a lot of the motivation for this is power-shifting and creating more independence, as well as shifting expenses from monthly-and-perpetual to one-time-cost, self-owned, self-hosted. How would WebRTC fit into that?

vriska commented 2025年10月23日 00:45:14 +02:00

If you changed the server to serve assets over a WebRTC tunnel and wrote an in-browser JS client to fetch assets, you (as in the project owner) could fairly cheaply host a single copy of that client as static assets plus STUN/TURN. This is AFAIK the only way for a browser to directly talk to a service behind a NAT without port forwarding. This would be easier for a static SPA, and proxying an MPA like this would be kind of a hack. I'm also not really convinced it's actually a great idea: UniFi's implementation of this hasn't been super reliable in my experience, and they've presumably put quite a bit of engineering effort into it.

If you changed the server to serve assets over a WebRTC tunnel and wrote an in-browser JS client to fetch assets, you (as in the project owner) could fairly cheaply host a single copy of that client as static assets plus STUN/TURN. This is AFAIK the only way for a browser to directly talk to a service behind a NAT without port forwarding. This would be easier for a static SPA, and proxying an MPA like this would be kind of a hack. I'm also not really convinced it's actually a great idea: UniFi's implementation of this hasn't been super reliable in my experience, and they've presumably put quite a bit of engineering effort into it.

zkat commented 2025年10月23日 00:51:43 +02:00

It sounds like something along the lines of tailscale funnel, where you literally have a single server proxying every request to the NAT-ed clients through a locally-running daemon. In that case, the only cost offset is hardware costs (you have to pay bandwidth now, at least), and you have to deal with a single point of failure...

It sounds like something along the lines of tailscale funnel, where you literally have a single server proxying every request to the NAT-ed clients through a locally-running daemon. In that case, the only cost offset is hardware costs (you have to pay bandwidth now, at least), and you have to deal with a single point of failure...

velvette commented 2025年10月23日 01:44:31 +02:00

The few solutions I can think of that are not STUN/TURN based as indeed I tend to agree that it's probably dead are gonna be stuff like doing some form tunneling though SSH, VPN or weird stuff with software VLAN.

All those solution require one or more exit public server that will pass through the content and I think this could land on the sort of issues that can encounter tor exit nodes for example.

EDIT: (french foss warning but website is in english) an example of some of this idea is the Internet Cube (Brique Internet in french) that uses a VPN through FFDN (grouping of French associative independent ISPs): https://internetcu.be/

The few solutions I can think of that are not STUN/TURN based as indeed I tend to agree that it's probably dead are gonna be stuff like doing some form tunneling though SSH, VPN or weird stuff with software VLAN. All those solution require one or more exit public server that will pass through the content and I think this could land on the sort of issues that can encounter tor exit nodes for example. EDIT: (french foss warning but website is in english) an example of some of this idea is the Internet Cube (Brique Internet in french) that uses a VPN through FFDN (grouping of French associative independent ISPs): https://internetcu.be/

forestjohnson commented 2025年10月24日 18:46:32 +02:00

Is there a way to do so without endangering their whole network?

I think the thing you want is called a TCP reverse tunnel. I made this diagram to help explain the etymology. https://picopublish.sequentialread.com/files/network-protocol-software-terminology2.jpg

It's possible to have multiple tunnels ( different computers in different locations) hosted by the same public IP address under different domain names.

Unfortunately, as far as I know, there aren't any economically competitive service providers offering this service for money yet. I tried to create one in ~2020 and ultimately gave up on it because the thing I made wasn't quite shaped right, and the interest that I saw was small and dwindling.

I believe most people, when they need this, will simply rent a VPS from DigitalOcean or something like that. Then they will install some sort of reverse tunnel software on the VPS. frp is probably my favorite, it has the best performance of any I've tried. It doesn't support SNI routing (TLS passthru for multiple domains) So if you want to support multiple different tunnels to different machines, you'll have to put something like haroxy in front of the frp listeners to route to different tunnels.

https://github.com/fatedier/frp

You can also simply use SSH, which is what we've been using in production for years:

https://wiki.cyberia.club/hypha/infrastructure_and_operations/reverse-tunnel

There are also some communities which have sprung up whose sole purpose is to share one of these VPSs and allow individuals access for tunneling at low or no cost.

https://gateway.commoninternet.net/info

Although I think those folks are using tail scale right now instead of a reverse tunnel, which means that there is a potential network over-sharing concern.

I'm planning on trying again to make a good reverse tunneling system (and instance of it ran as a compettitively priced commercial service) in the future .. But it has a long way to go still.

> Is there a way to do so without endangering their whole network? I think the thing you want is called a TCP reverse tunnel. I made this diagram to help explain the etymology. https://picopublish.sequentialread.com/files/network-protocol-software-terminology2.jpg It's possible to have multiple tunnels ( different computers in different locations) hosted by the same public IP address under different domain names. Unfortunately, as far as I know, there aren't any economically competitive service providers offering this service for money yet. I tried to create one in ~2020 and ultimately gave up on it because the thing I made wasn't quite shaped right, and the interest that I saw was small and dwindling. I believe most people, when they need this, will simply rent a VPS from DigitalOcean or something like that. Then they will install some sort of reverse tunnel software on the VPS. `frp` is probably my favorite, it has the best performance of any I've tried. It doesn't support SNI routing (TLS passthru for multiple domains) So if you want to support multiple different tunnels to different machines, you'll have to put something like haroxy in front of the `frp` listeners to route to different tunnels. https://github.com/fatedier/frp You can also simply use SSH, which is what we've been using in production for years: https://wiki.cyberia.club/hypha/infrastructure_and_operations/reverse-tunnel There are also some communities which have sprung up whose sole purpose is to share one of these VPSs and allow individuals access for tunneling at low or no cost. https://gateway.commoninternet.net/info Although I think those folks are using tail scale right now instead of a reverse tunnel, which means that there is a potential network over-sharing concern. I'm planning on trying again to make a good reverse tunneling system (and instance of it ran as a compettitively priced commercial service) in the future .. But it has a long way to go still.

forestjohnson commented 2025年10月24日 18:56:59 +02:00

And then, of course, there's Cloudflare tunnels, which is the pay with your data option. From what I've heard, it actually works really well.... I just don't like Cloudflare.

And then, of course, there's Cloudflare tunnels, which is the pay with your data option. From what I've heard, it actually works really well.... I just don't like Cloudflare.

zkat commented 2025年10月24日 18:59:26 +02:00

I think there's some potential value in distributing a number of "proxy servers" across different polities/hosts that folks can connect to, where we/they would "just" charge for bandwidth usage and maybe domain setup stuff.

The big catch with anything like this is that those servers are then responsible for content moderation, which isn't ideal, but is probably as good as we're gonna get.

I think there's some potential value in distributing a number of "proxy servers" across different polities/hosts that folks can connect to, where we/they would "just" charge for bandwidth usage and maybe domain setup stuff. The big catch with anything like this is that those servers are then responsible for content moderation, which isn't ideal, but is probably as good as we're gonna get.

forestjohnson commented 2025年10月24日 19:03:23 +02:00

Ultimately, though, there is no One-time-cost entirely self-hosted solution for this problem. The best you can get is logging into the home router and configuring port forwarding. But like you said, not everyone is able to do that.

But as long as one person can do it they could act as a gateway for everyone else. It's just a matter of setting up the Social organization and the software to make it happen.

Ultimately, though, there is no One-time-cost entirely self-hosted solution for this problem. The best you can get is logging into the home router and configuring port forwarding. But like you said, not everyone is able to do that. But as long as one person can do it they could act as a gateway for everyone else. It's just a matter of setting up the Social organization and the software to make it happen.

zkat commented 2025年10月24日 19:13:54 +02:00

Yes, that seems to be the case. It seems like we can do a thing where there's shared costs for small proxy hosts, and then one-time-costs for the actual shop owners. I think if we can reduce the monthly cost of this shared proxy to sub-$ per stall, that's a win, and we can just make it easy to spin up proxies so folks can host them in different VPSes with different policies in different countries, in order to find a balance that fits their needs? Like I'm sure a 4ドル droplet is able to handle a lot of passthrough traffic, yeah? That's 500GiB outbound/mo free plus 0ドル.01 / GiB after that. Small collectives can easily pool stuff and pay basically nothing to share the load. You can get even cheaper hosting for "sensitive" content with something like nearlyfreespeech, which'll take you all the way down to like 2ドル-3 and let you host nsfw

Yes, that seems to be the case. It seems like we can do a thing where there's shared costs for small proxy hosts, and then one-time-costs for the actual shop owners. I think if we can reduce the monthly cost of this shared proxy to sub-$ per stall, that's a win, and we can just make it easy to spin up proxies so folks can host them in different VPSes with different policies in different countries, in order to find a balance that fits their needs? Like I'm sure a 4ドル droplet is able to handle a lot of passthrough traffic, yeah? That's 500GiB outbound/mo free plus 0ドル.01 / GiB after that. Small collectives can easily pool stuff and pay basically nothing to share the load. You can get even cheaper hosting for "sensitive" content with something like nearlyfreespeech, which'll take you all the way down to like 2ドル-3 and let you host nsfw

velvette commented 2025年10月24日 20:56:45 +02:00

OVH servers and VPS usually have bandwidth limitations but no total data cap for example and I think they're not the only actors to do that so it could even be better.

OVH servers and VPS usually have bandwidth limitations but no total data cap for example and I think they're not the only actors to do that so it could even be better.

forestjohnson commented 2025年10月24日 21:27:34 +02:00

W/ my old "greenhouse" project I was planning on charging 0ドル.01 per GB or so, which would come out to less than 1ドル/year for most sites unless they are extremely popular or they do video or large downloads.

This is still an area where I can't point to a single solution that just works every time, But once the initial connection is established through the tunnel, it's possible to securely transfer large high bandwidth stuff (video) through other means like WebRTC and or tcp over alternate ports opened by universal plug n play (UPnP).

This would be a lot of software development work to set up, but I do think it's a cool idea and I hope to see folks using it. I believe that peertube already does this using webtorrent.

I've also written about it a couple times: https://sequentialread.com/serviceworker-webrtc-the-p2p-web-solution-i-have-been-looking-for/

And also this super deranged Dr. Bronners style screed: https://git.sequentialread.com/forest/tuber

I did investigate WebTorrent once or twice and by modifying the trickle ice settings and hosting my own WebTorrent tracker, I was able to get the connection time for starting a download down to the milliseconds range. (In the most ideal conditions of everything being on the same host) https://picopublish.sequentialread.com/files/stream_clip_2022年01月02日_17-20/

Anyways I don't know anything about this Silverfish project, but I have been very interested in hosting at home for a long time and how to make it easier for folks.

I think that.. These types of problems might best be solved by a hosting platform project not necessarily by individual apps. In an ideal world, a share-able hosting platform system can be created which can be installed on your computer at home and then you would be able to host any app through it, Or even combine it with existing app recipe books that don't help deal with nat traversal like yunohost, coop cloud, etc. And maybe most importantly, share it by giving your friends accounts on there that they can use to host things.

Anyways, it's up to you how 2 approach it. The project I'm working on is being written in Go right now. Its goals are to be an ez to use virtual machine manager w/ libvirt, backup manager w/ virtnbdbackup, and also support tunneling. "Version 2" of https://git.cyberia.club/cyberia/capsul-flask/ but w/ a focus on self hosting

W/ my old "greenhouse" project I was planning on charging 0ドル.01 per GB or so, which would come out to less than 1ドル/year for most sites unless they are extremely popular or they do video or large downloads. This is still an area where I can't point to a single solution that just works every time, But once the initial connection is established through the tunnel, it's possible to securely transfer large high bandwidth stuff (video) through other means like WebRTC and or tcp over alternate ports opened by universal plug n play (UPnP). This would be a lot of software development work to set up, but I do think it's a cool idea and I hope to see folks using it. I believe that peertube already does this using webtorrent. I've also written about it a couple times: https://sequentialread.com/serviceworker-webrtc-the-p2p-web-solution-i-have-been-looking-for/ And also this super deranged Dr. Bronners style screed: https://git.sequentialread.com/forest/tuber I did investigate WebTorrent once or twice and by modifying the trickle ice settings and hosting my own WebTorrent tracker, I was able to get the connection time for starting a download down to the milliseconds range. (In the most ideal conditions of everything being on the same host) https://picopublish.sequentialread.com/files/stream_clip_2022年01月02日_17-20/ Anyways I don't know anything about this Silverfish project, but I have been very interested in hosting at home for a long time and how to make it easier for folks. I think that.. These types of problems might best be solved by a hosting platform project not necessarily by individual apps. In an ideal world, a share-able hosting platform system can be created which can be installed on your computer at home and then you would be able to host any app through it, Or even combine it with existing app recipe books that don't help deal with nat traversal like yunohost, coop cloud, etc. And maybe most importantly, share it by giving your friends accounts on there that they can use to host things. Anyways, it's up to you how 2 approach it. The project I'm working on is being written in Go right now. Its goals are to be an ez to use virtual machine manager w/ libvirt, backup manager w/ virtnbdbackup, and also support tunneling. "Version 2" of https://git.cyberia.club/cyberia/capsul-flask/ but w/ a focus on self hosting

zkat commented 2025年10月26日 16:32:16 +01:00

@forestjohnson silverfish is a self hosted e-commerce server. Think woocommerce/wordpress. The reason this thread is open and the idea is being explored is because we’re thinking of selling/distributing standalone IoT "appliances" that come preloaded with it, and where you can host your content from.

The problem is getting the outside world to be able to talk to them, because a very important requirement to all of this is that it be turnkey and NOT require much, if any, technical ability from the folks who are running these shops. It should just work.

@forestjohnson silverfish is a self hosted e-commerce server. Think woocommerce/wordpress. The reason this thread is open and the idea is being explored is because we’re thinking of selling/distributing standalone IoT "appliances" that come preloaded with it, and where you can host your content from. The problem is getting the outside world to be able to talk to them, because a very important requirement to all of this is that it be turnkey and NOT require much, if any, technical ability from the folks who are running these shops. It should just work.

benlittle commented 2025年10月30日 21:34:49 +01:00

edited for clarity

There are only three ways to deal with NAT:

1. Properly configured DNAT firewall rules on the NAT gateway (there may be multiple in large network environments like a university)
2. Reverse proxying, where the stall device would need to establish an outgoing connection to a public server, which then proxies requests from clients to the stall device
3. UDP hole punching, where clients connect directly to stall using an intermediary to exchange UDP IP/Port information

The first solution just bypasses the issue by assuming control over the NAT gateway. The second requires a high-throughput server, at which point a physical stall device doesn't serve much purpose. That leave us with the third option, discussed below.

UDP Hole Punching with WebRTC

As far as I am aware the only widely-implemented browser API that can establish a P2P connection is WebRTC.

As for an implementation I recommend Libp2p WebRTC.

The major advantage here is that this library is designed for establishing secure message-oriented P2P connections. It also offloads the responsibility of NAT discovery and Peer Address resolution to a general P2P service that is already widely available. The custom indexer just needs to map each stall's information to a long-lived PeerID.

sequenceDiagram
 Participant Stall
 Participant Swarm
 Participant Indexer
 Participant Client
 Stall->>Stall: Generate PeerID
 Stall->>Indexer: I am PeerID
 %% AutoNAT
 Stall->>Swarm: What is NAT Addr?
 Swarm->>Stall: NAT addr is IP/Port
 %% PeerID Broadcast
 Stall->>Swarm: PeerID avail at IP/Port
 %% Custom
 Client->>Indexer: Who is Stall?
 Indexer->>Client: Stall is PeerID
 %% PeerID Resolution
 Client->>Swarm: Where is PeerID?
 Swarm->>Client: PeerID at IP/Port
 %% WebRTC Transport:
 Client->>Stall: Secure Connection

Indexer

An indexing service should allow stall operators to perform two tasks:

1. Update stall information for clients to search and view.
2. Advertise their PeerID.

Indexers would probably also choose to supply a web app for clients to connect to stalls using WebRTC like above, but this isn't required as the client could bring their own app and only use the indexer to find stall information.

Keep in mind the indexer could be as simple as a stall operator sharing their PeerID via a generated QR code or similar. DNS TXT record is also an option, with the browser client making use of DNS over HTTPS.

_edited for clarity_ There are only three ways to deal with NAT: 1. Properly configured DNAT firewall rules on the NAT gateway (there may be multiple in large network environments like a university) 2. Reverse proxying, where the stall device would need to establish an outgoing connection to a public server, which then proxies requests from clients to the stall device 3. UDP hole punching, where clients connect directly to stall using an intermediary to exchange UDP IP/Port information The first solution just bypasses the issue by assuming control over the NAT gateway. The second requires a high-throughput server, at which point a physical stall device doesn't serve much purpose. That leave us with the third option, discussed below. ## UDP Hole Punching with WebRTC As far as I am aware the only widely-implemented browser API that can establish a P2P connection is WebRTC. As for an implementation I recommend [Libp2p WebRTC](https://docs.libp2p.io/concepts/transports/webrtc/). The major advantage here is that this library is designed for establishing secure message-oriented P2P connections. It also offloads the responsibility of NAT discovery and Peer Address resolution to a general P2P service that is already widely available. The custom indexer just needs to map each stall's information to a long-lived PeerID. ```mermaid sequenceDiagram Participant Stall Participant Swarm Participant Indexer Participant Client Stall->>Stall: Generate PeerID Stall->>Indexer: I am PeerID %% AutoNAT Stall->>Swarm: What is NAT Addr? Swarm->>Stall: NAT addr is IP/Port %% PeerID Broadcast Stall->>Swarm: PeerID avail at IP/Port %% Custom Client->>Indexer: Who is Stall? Indexer->>Client: Stall is PeerID %% PeerID Resolution Client->>Swarm: Where is PeerID? Swarm->>Client: PeerID at IP/Port %% WebRTC Transport: Client->>Stall: Secure Connection ``` ## Indexer An indexing service should allow stall operators to perform two tasks: 1. Update stall information for clients to search and view. 2. Advertise their PeerID. Indexers would probably also choose to supply a web app for clients to connect to stalls using WebRTC like above, but this isn't required as the client could bring their own app and only use the indexer to find stall information. Keep in mind the indexer could be as simple as a stall operator sharing their PeerID via a generated QR code or similar. DNS TXT record is also an option, with the browser client making use of DNS over HTTPS.

jeromegn commented 2025年12月27日 21:15:46 +01:00

This is a very hard problem indeed!

It might be easier to come up with solutions if we had a "censorship threat model" (for lack of a better name). For example, I doubt we'd want people to host a DNS server themselves, so it probably means that we're OK with using a hosted DNS provider. However, DNS providers can definitely take your site down.

Short of asking Conjured Ink users' clients to use a special browser, I don't think it's possible to be completely censorship-proof.

A client-side P2P library could reach a home server and render HTML/JS/CSS from it to the user's browser, but that would require trusting DNS, a small HTTPS server and a P2P relay server. I also doubt that this setup would be able to satisfy a Let's Encrypt ACME challenge to generate a certificate.

Simplest I can think of is, as part of the one-time fee, there would be a setup fee where a human helps the user to configure port forwarding properly (perhaps not as part of the one-time fee, could be an extra support fee). Then again, some ISPs block inbound connections to certain port ranges (or all of them). A shop owner would have to first check if their ISP and their hardware would work.

This is a very hard problem indeed! It might be easier to come up with solutions if we had a "censorship threat model" (for lack of a better name). For example, I doubt we'd want people to host a DNS server themselves, so it probably means that we're OK with using a hosted DNS provider. However, DNS providers can definitely take your site down. Short of asking Conjured Ink users' clients to use a special browser, I don't think it's possible to be completely censorship-proof. A client-side P2P library could reach a home server and render HTML/JS/CSS from it to the user's browser, but that would require trusting DNS, a small HTTPS server and a P2P relay server. I also doubt that this setup would be able to satisfy a Let's Encrypt ACME challenge to generate a certificate. Simplest I can think of is, as part of the one-time fee, there would be a setup fee where a human helps the user to configure port forwarding properly (perhaps not as part of the one-time fee, could be an extra support fee). Then again, some ISPs block inbound connections to certain port ranges (or all of them). A shop owner would have to first check if their ISP and their hardware would work.

zkat commented 2025年12月27日 22:43:24 +01:00

The goal here is partially censorship-related but also heavily about amortizing hosting costs by deploying very low-cost, preconfigured appliances with silverfish installed on them that could live in someone’s closet.

In this scenario, I think it’s acceptable to have a "standard" forwarding server that can pass on bandwidth costs to the sellers that only takes over the job of handling all the DNS and port forwarding stuff, and we can have a standard interface for connecting the appliances with a selection of available servers, so anyone can spin them up on a range of cloud hosts with different permissiveness/costs/locations

The goal here is partially censorship-related but also heavily about amortizing hosting costs by deploying very low-cost, preconfigured appliances with silverfish installed on them that could live in someone’s closet. In this scenario, I think it’s acceptable to have a "standard" forwarding server that can pass on bandwidth costs to the sellers that only takes over the job of handling all the DNS and port forwarding stuff, and we can have a standard interface for connecting the appliances with a selection of available servers, so anyone can spin them up on a range of cloud hosts with different permissiveness/costs/locations

vriska commented 2025年12月28日 14:33:17 +01:00

The goal here is partially censorship-related but also heavily about amortizing hosting costs by deploying very low-cost, preconfigured appliances with silverfish installed on them that could live in someone’s closet.

I don't think that this would actually be cheaper: a server that costs 50x as much as an applicance could likely run well over 50 instances of the application. If the application is cheap enough to run, I don't think it would be impossible to make a fairly low lifetime fee for a hosted instance economical.

> The goal here is partially censorship-related but also heavily about amortizing hosting costs by deploying very low-cost, preconfigured appliances with silverfish installed on them that could live in someone’s closet. I don't think that this would actually be *cheaper*: a server that costs 50x as much as an applicance could likely run well over 50 instances of the application. If the application is cheap enough to run, I don't think it would be impossible to make a fairly low lifetime fee for a hosted instance economical.

zkat commented 2025年12月28日 16:08:32 +01:00

In concrete terms: the application is able to run well on 30ドル of hardware. Even if we take our own cut selling the stuff and bump it up, it’ll pay for itself in roughly a year, compared to the cheapest hosts

In concrete terms: the application is able to run well on 30ドル of hardware. Even if we take our own cut selling the stuff and bump it up, it’ll pay for itself in roughly a year, compared to the cheapest hosts