[clearleaf]

The incredible technology you're describing was possible on the Nintendo DS without wires and no need for a LAN either. It's a problem that's been solved in hundreds of different ways over the last 40 years but certain people don't want that problem to ever be solved without cloud services involved.

This dumb pipe thing is certainly interesting but it will run into the same problem as the myriad other solutions that already exist. If you're trying to give a 50MB file to a Windows user they have no way to receive it via any method a Linux user would have to send it unless the Windows user has gone out of their way to install something most people have never heard of.

[deathanatos]

> It's a problem that's been solved in hundreds of different ways over the last 40 years

If we put the requirements of,

  1. E2EE
  2. Does not rely on Google. (Or ideally, any other for profit corporation.)

That eliminates like 90% of the recent trend of WebRTC P2P file transfer things that have graced HN over the last decade, as all WebRTC code seems to just copy Google's STUN/TURN servers between each other.

But as you say,

> but certain people don't want that problem to ever be solved without cloud services involved.

ISPs seem to be that in set. IPv6 would obsolete NAT, but my ISP was kind enough to ship an IPv6 firewall that by default drops incoming packets. It has four modes: drop everything, drop all inbound, a weird intermediate mode that is useless¹, and allow everything.

(¹this is Verizon fios; they claim, "This feature enables "outside-to-inside" access for IPv6 services so that an "outside" Internet service (gaming, video, etc.) can access a specific "inside" home client device & port in your local area network."; but the feature, AFAICT, requires the external peer's address. I.e., I need to know what my roaming IP will be before I leave the house, somehow, and that's obviously impossible. It seems utterly clearly slapped on to say "it comes with a firewall" but was never used by anyone at Verizon in the real world prior to shipping…)

[genewitch]

starlink doesn't even give you publicly routable ipv6 unless you bypass the starlink router.

My starlink is such that i cannot install/set up things like pfsense/opnsense because the connection drops sometimes, and when either of those installers fail, they fail all the way back to "format the drive y/n?" Also, things like ipcop and monowall et al don't seem to support ipv6.

I looked in to managing ipv6 from a "i am making my own router" and no OS makes this simple. i tried with debian, and could not get it to route any packets. I literally wrote the guide for using a VM for ipcop and one of the "wall" distros; but something about ipv6 just evades me.

[deathanatos]

> starlink doesn't even give you publicly routable ipv6 unless you bypass the starlink router.

If you've not got an Internet[-routable] address, are you truly connected to the Internet?

> I looked in to managing ipv6 from a "i am making my own router" and no OS makes this simple. i tried with debian, and could not get it to route any packets. I literally wrote the guide for using a VM for ipcop and one of the "wall" distros; but something about ipv6 just evades me.

TBH, I would think that this is just enabling v6 forwarding. That wouldn't do RA or DHCP, I don't think, but I don't think you'd want that, either. (That would be the responsibility of the upstream network.)

[Dagger2]

You would want that. The upstream network can't do it for you, because RAs can't be routed. Same deal for DHCPv6 (although personally I'd say you can probably skip that and just use SLAAC).

[genewitch]

in order to have public ipv6 on starlink you need to manage the /56 they delegate to you into however many /64s that is (at least 8); i tested it with a store bought router, everything worked if you can do PD with DHCP[v6] or whatever. I returned the router because it was $200 and i will eventually figure it out on a VM.

[Dagger2]

It's pretty simple with systemd-networkd:

  # On the upstream network.
  [Network]
  DHCP=yes
  [DHCPv6]
  PrefixDelegationHint=::/56

  # On each downstream network.
  [Network]
  IPv6SendRA=yes
  DHCPPrefixDelegation=yes

If you don't want systemd-networkd, look at https://wiki.debian.org/IPv6PrefixDelegation#Using_ifupdown_.... Firewalling is the same as v4, just without the NAT.

One frustrating part is that as far as I can tell nothing supports easy downstream DHCPv6-PD delegation, so machines on the downstream network that want their own prefix won't be able to get one automatically. OpenWRT's network config daemon supports it, but nothing on regular Linux does.

> however many /64s that is (at least 8);

256!

[loloquwowndueo]

Pairdrop.net - no need to install anything, transfers go over the local network if both devices are in a LAN.

[elliotec]

I mean, windows users install things they’ve never heard of all the time.

If this was a real thing you needed to do, and it is too much work to get them to install WSL, you could probably just send them the link to install Git and use git bash to run that curl install sh script for dumbpipe.

And if this seemed like a very useful thing, it couldn’t be too hard to package this all up into a little utility that gets windows to do it.

But alas, it remains “easier” to do this with email or a cloud service or a usb stick/sd card.

[kovek]

> It's a problem that's been solved in hundreds of different ways over the last 40 years

I guess now you can find the solution that you need by telling the requirements to LLMs who have now indexed a lot of the tradeoffs