我是打算闲下来了先试着开发中心化区块链，中心服务器搞记账，链透明，用户转发中心服务器或其他用户流量盈利，然后发布消息消费，kad 网络广播（只转发到比来源桶小的节点），用户接到消息后签名回应，然后发布者打钱。

以上准确的说是聊天室的想法了，如果是点对点双人通讯就不用广播，能互联就免费，要租用就按流量计费

等情况稳定了再考虑去中心化，中心服务器主要记账和同步链指针，也参与 kad 做 tracker （这个不大重要）

此外，国内外有大量 stun 服务器，例如腾讯，虽然隐私确实不好把控，但是作为公用节点没有太大问题

@mokiki 欠账只能用于小组群，不适合大规模推广。此外，无限欠账也是个问题，滥用还是解决不了

关于 nat ，其实不是什么太大的问题。
我最近也在考虑这个（国内局势有点紧），nat 可以用 stun 技术解决大部分互联。
绝大多数家宽是限制端口锥或限制锥，n2n 成功率不低。学校或公司的对称型才是最大障碍。

我的想法是用户激励，由于 nat 穿透存在，大部分人都可以互联，少部分可以租用别人的带宽，通过中继出去。
用户激励可以类似 btc 那种发行代币，但是维护成本高。不激励随便用很容易造成滥用，这也是个头疼的点。

我自己计划是 kad ，纯浏览器，webrtc ，rsa 端对端加密，这是没有问题的。

可以收集别人的值然后嫁祸别人

现在已经不是什么 natv4 的问题了，最扯淡的是 natv6 要来了

NoVNC ，用官方 Websockify 将 VNC 信号 TCP 转 WebSocket ，在最高压缩最低质量环境下，大约 20fps

至于 RDP ，目前我没找到什么好的 Web 。

此外，谷歌远程桌面有 STUN 功能，可以 NAT 穿透。只要首次挂上梯子链接，接下来全走 N2N 速度很快

@wbd31 问题是内路由也是 CF ，也是免流量啊。我的意思是用 Worker 拉 API 是脱裤子放屁的行为，直接 CNAME 过去就行了

这个。。。为什么要用 Worker

如果只是为了隐藏 Bucket 名，你可以用 CF 自带的内路由功能隐藏。

如果怕被公开，可以设置一个专门用于 CF 的 Bucket 名，名字长一点就不会被扫到了

这个问题我先前浅浅的思考过，原文在这里

<https://blog.cyfan.top/p/c0af86a9.html> 为什么是 APP 而不是网页

@jorneyr 一时间无言以对...

F12 直接冲 document.getElementById('wxcode_box').style["display"] = "none"

感觉就是非常的粗糙。。。

就不谈速度了，cfpage 的沙雕路由跳转会强迫抹去.html 后缀、路由强制返回一个 /，我在社区里面抱怨过了官方人员回复这是“有益的默认规则”，简直就是脑残。

不过 cfpage 的函数和 cfworker 的计量是分开的，而且 worker 脚本只要稍作修改就可以跑在 page 里，再加上 cfpage 有一个 cname 接入的功能。总而言之这是除了 SaaS 之外唯一能 CNAME 接入 cf 的方式了。

cfpage 本身无限流量，可以存放一些静态资源。建站的话除非被打了，否则不太建议。

@zckevin 唔，使用了 ServiceWorker 或 workbox 通常会存在 缓存无限填充不删除、一瞬间缓存过多文件或者重安装假死的问题，这个是网上泛滥的教程里面都没解决的问题。我博客的 ChenBlogHelper 和 ClientWorker 都对此进行了优化，缓存重填充和按请求填充的方式能够很好解决这些问题。目前我博客缓存占用保持在 10M-200M 之间，相较于动辄 2G-5G 的缓存已经好了不少

@zckevin 哈？具体有啥难受能说一说吗

@yanyaovo 可以啊，如果 v2 上解释不清可以去提 issue

@nonone 你也不看看参加人员都是些什么牛鬼蛇神。。。没有一个大国，唯一的发达国家是韩国，其他全是舆论审查极其严重的国家，这其实就是一个“墙”国交流大会。。。

4GB 内存用户表示瑟瑟发抖，日常轻量办公娱乐不受影响