gogogo2000

@wuzhewuyou react signal 表示，啊？难道这不是趋势？

Here’s a parting “TL;DR” recap: For robust NAT traversal, you need the following ingredients:

A UDP-based protocol to augment

Direct access to a socket in your program

A communication side channel with your peers

A couple of STUN servers

A network of fallback relays (optional, but highly recommended)

Then, you need to:

Enumerate all the ip:ports for your socket on your directly connected interfaces

Query STUN servers to discover WAN ip:ports and the “difficulty” of your NAT, if any

Try using the port mapping protocols to find more WAN ip:ports

Check for NAT64 and discover a WAN ip:port through that as well, if applicable

Exchange all those ip:ports with your peer through your side channel, along with some cryptographic keys to secure everything.

Begin communicating with your peer through fallback relays (optional, for quick connection establishment)

Probe all of your peer’s ip:ports for connectivity and if necessary/desired, also execute birthday attacks to get through harder NATs

As you discover connectivity paths that are better than the one you’re currently using, transparently upgrade away from the previous paths.

If the active path stops working, downgrade as needed to maintain connectivity.

Make sure everything is encrypted and authenticated end-to-end.

tailscale 会自动创建 upnp 端口映射的，所以
> 我的想法是，打洞失败，既然能连接 derp 服务器，那就能控制另一端，搞个脚本，让另一台设备主动请求 OpenWrt （ upnp/nat-pmp)开放一个临时端口。然后 tailscale 是否支持这样搞？
人家本来是这样的。

> tailscale 是暴力遍历端口（它们官网有教程），实践下来还是能够打洞成功的。
tailscale 是生日算法，并不是暴力遍历 https://tailscale.com/blog/how-nat-traversal-works
"But we can get rid of STUN, the birthday paradox trick, port mapping protocols, and all the hairpinning bumf. That’s much nicer!"

@zombiej 是的，实际上 rc 基本上也是蚂蚁的人写的，但是这种套娃的写法使得找实现和做优化修改难度剧增，很多功能都是套了好几层才暴露出来的，需要花很大力气才能搞清楚最终实现

@yuhuij #25 keep-alive 有个实验性的 activity： https://react.dev/reference/react/Activity

路由守卫什么的需要自己写

@yuhuij #13 你会发现 antd 整个基本就是 rc 的壳，几乎所有控件最终都会调用 rc-*控件

js 的对象无论是 getter/setter 还是 proxy 都是一个对象，你直接把对象给替换了，当然就无法监听变化了
ref 无论你怎么替换，实际上你置换的都是对象的.value 值。

基本上你可以理解为 ref=reactive{ value: ??? }，所以使用 ref 时，ref 对象本身永久都不会变，自然总是可以监听到变动

域名被分配到了.1 了，不过还可以正常访问。
感觉免费的就很可能会被分配过去，我从来没有用任何域名+cf 做过代理等滥用的情况，也不是新号

现在主流密码管理器的设计在服务器上存放的都是高度加密的密文，而打开密码库的主密钥从头到尾是不会在网络上传输的，即便被监听了也抓不到。但如果是访问者中了木马被记录键盘了自然就另当别论了。