test1 发布的帖子

@wumingshi 有一个tag nomadmatters

https://matters.town/tags/157201-nomadmatters

作为站务我能考虑到的是pkuanvil不是未名树洞，这一点很多用户都不愿意接受（很多游客发帖是已注册用户的马甲）
这个说起来就复杂了，作为站务我也不知道怎么处理…
但是完全允许游客发言是不太可能的，允许游客发言本来就是临时措施

这会引入额外成本，首先我不认为需要为游客发帖付出这么多成本（开通openai帐号本身就是成本） 而且如何向gpt解释审查标准也是一个问题

因为游客发言的下限太低了。导火索是有bot往#435这个帖子里面刷假药广告
如果注册用户发类似帖子会视情节轻重补刷屏tag，给警告或禁言等等，但是游客的话这些都没有意义，因为bot它不会理解站务说的任何话，就是直接删帖

对游客默认信任是不行的，因为站务也不是AI，能24小时在线绝对不会误伤正常发言，站务不在的时候出什么事都有可能，而注册用户大量灌水发垃圾贴的概率就低很多

@wumingshi 有可能，不是全部也至少有一部分

示例页面

为了证明您有良好的 OCR 处理流程，您可以从以下的来自一本有关半导体的书的示例页面开始。您的流程应当正确处理数学，表格，图表，脚注等等。

将您处理好的页面发送到 AnnaArchivist@proton.me 。如果它们看上去良好，我们会私下向您发送更多页面，并且我们期待您能够在这些页面上快速运行您的流程。当我们满意的时候我们就能达成协议。

Anna’s Archive 获得了754万本/359TB 来自读秀（超星电子图书馆）的电子书。读秀的这些电子书已经在中文互联网上长期盗版，被二次销售时通常低于1美元。即使如此，大批量地获得这些书是很难的。Anna’s Archive 一直将这放在TODO list上，并分配了好几个月全职工作在这方面。

不过，有志愿者联系了 Anna’s Archive，表示他们以高昂的代价已经获得了这些书。他们分享了收藏的所有书给 Anna’s Archive，没有索取任何回报，（当然）条件是要长期保存这些书。他们同意在将这些书 OCR 的过程中寻求帮助。

Anna’s Archive 正在寻求来自 LLM 公司或学术机构的帮助。高质量的学术图书非常有利于 LLM 的训练，尽管这些书是用中文写的，但无论源语言是什么，模型都能理解概念和知识。Anna’s Archive 愿意给予您一年的大规模独家访问权限。如果您愿意与我们分享整个流程的代码，我们愿意将该收藏品禁运更长时间。当然，在禁令失效以后 Anna’s Archive 会发布整个收藏。

https://annas-blog.org/duxiu-exclusive.html

@wumingshi 几百M

matters看上去发文章非常活跃 但是据说流量并不多？不太了解
可能和matters本身用户的特点有关吧，以及matters站方运营也非常积极

mirror也很荒芜，matters就还蛮活跃的。我感觉差别在于，matters社区有在努力“经营”社区，有ali、多比这样非常nice的人一直在鼓励大家表达和互动。对社区而言，鼓励是最重要的，也是很辛苦的。
让鼓励可以持续，可能是每个社区都需要面对的事情

https://crossbell.io/notes/38189-27

另外 piping-server 的一个问题是 /aaa 和 /bbb 等等 URL 每次只能一个 TCP 入站/出站连接配对，即不能多个 TCP 连接都连接到 /aaa 和 /bbb。这个可能会让部署略显复杂，需要更精巧的脚本去自动生成这些 URL 避免冲突，而且还需要 Server 端主动监听这些 URL（各种内网穿透的方案都需要被穿透方主动配合，因为 piping-server 或者 frp 都不能主动对被穿透方发起 TCP 连接）

需要和基于 frp 的方案做更细致的比较。比较明显的一个优势是 HTTP 服务器可用性更高，特别是大量 CDN 都只支持 HTTP

原文：Secure TCP tunnel from anywhere with curl and nc for single connection（原理介绍）
（另一篇文章 The Power of Pure HTTP – screen share, real-time messaging, SSH and VNC 举了大量浏览器前端中实现 ssh、屏幕共享、VNC的例子，没有讲述原理，但是这种基于 HTTP 的 TCP 管道式代理方法本身不仅限于浏览器中使用）
Github 项目：https://github.com/nwtgck/piping-server

原理不复杂，就是用 HTTP 转发 TCP 流量。这个只需要 HTTP 服务器就可以用（绝大多数 CDN 都只支持 HTTP）

举例：假设 https://ppng.io 是部署了原文所说的 piping-server，在自己的 Server 上（比如在 22 端口启动了 sshd），使用如下命令启动入站和出站 TCP 隧道：

# server host
curl -sSN https://ppng.io/aaa | nc localhost 22 | curl -sSNT - https://ppng.io/bbb

然后在要自己的 Client 端，使用如下命令启动出站和入站 TCP 隧道：

# client host
curl -sSN https://ppng.io/bbb | nc -lp 2222 | curl -sSNT - https://ppng.io/aaa

最后在 Client 端连接到本地的 2222 端口：

ssh -p 2022 root@127.0.0.1

中间使用了辅助的命令 curl 和 nc 作为 TCP 流量管道。

Server 端：

1. curl -sSN https://ppng.io/aaa：让 curl 从 https://ppng.io/aaa 读取输入，安静输出（-sS）并流式（-N）输出到 stdout（Server 监听 /aaa）
2. nc localhost 22：将上一步的输出管道接到 Netcat 并发送到localhost的 22 端口
3. curl -sSNT - https://ppng.io/bbb：将上一步的输出管道接到 curl 并上传（-T）到https://ppng.io/bbb，流式（-N）安静输出（-sS），中间的 - 表示从 stdin 输入（Server 返回结果到 /bbb）

Client 端：

1. curl -sSN https://ppng.io/bbb：让 curl 从 https://ppng.io/bbb 读取输入，安静输出并流式输出到 stdout（Client 监听 /bbb)
2. nc localhost 22：将上一步的输出管道接到 Netcat，同时让 Netcat 监听（-l）本地的 2222 端口
3. curl -sSNT - https://ppng.io/bbb：将上一步的输出管道接到 curl 并上传到https://ppng.io/bbb，流式安静输出，中间的 - 表示从 stdin 输入（Client 发送请求到 /aaa）

上面两步只是建立了 TCP 流量转发流程，并未真正启动 ssh 会话，最终的 ssh 会话由 ssh 客户端启动：ssh -p 2022 root@127.0.0.1

整个流程图示如下：

----------------------------------------------------------------------------------
|          [Client]          |   https://ppng.io   |           [Server]          |
|---------------------------------------------------------------------------------
|    (Client TCP Upload)     |                     |      (Server TCP Download)  |
|     ---->     ---> curl ---|-->      /aaa     ---|--> curl --->     ---->      |
| ssh        nc              |                     |              nc        sshd |
|     <----     <--- curl <--|---      /bbb     <--|--- curl <---     <----      |
|    (Client TCP Download)   |                     |      (Server TCP Upload)    |
----------------------------------------------------------------------------------

微博类网站始终存在一个社区认同的问题（当然它也不关心什么是社区，毕竟这只是从BBS角度对它的指责，它更关心"我有一个号每天晒日常等评论来贴贴我"） 猜测即使Discourse和NodeBB未来引入ActivityPub插件，也会在评论和互动做出诸多身份限制使得它们不是真正意义上去中心化社交网络的一部分

现在来看，Discourse 官方已经给了 ActivityPub 插件了：https://meta.discourse.org/t/activitypub-plugin/266794

但是从描述来看实现很弱，基本是只读而且评论不导入Discourse，那为什么不用已经成熟的RSS/Atom feed……可能是因为传统BBS论坛本身设计目标就和微博类网站不一样吧，更关心讨论问题的社区，而不是构建博主的社交圈

matters上的镜像
中文互联网中“讨论”的消亡
即便拥有完美的公共领域，“讨论”依旧不可能存在吗？

作为站长最关心的问题“讨论空间需要啥特点”没给出作者的论述，很着急。。。

和"CS"其实没什么关系，更加需要熟练使用搜索引擎的技能。管理一个服务器其实很多知识都比较细碎。（其实是站长也忘了怎么知道这么多的）

按教程搭建不难，但是要持续维护稳定性，修复bug，甚至还要开发新功能的话难度就陡然上升了，需要一定的编程能力。CS 专业其实在这方面用处不大，因为小规模的论坛既不需要像互联网公司动不动就高并发，也不需要你去造底层的轮子，倒是更加需要耐心和阅读新代码的能力

如题，888888（注册用户应该都收到系统提示了吧……？）

像Mastodon之类比较大的API短期内不会有（Mastodon可能有NodeBB和Discourse的官方支持：https://www.pkuanvil.com/topic/443/能否在本站开启activitypub ，不过我和交大门站长都没有自己支持的意愿，基本上就是坐等官方支持了）。

小的集成可能有，比如说我在pkuanvil做一个界面展示交大门的帖子，手动搬运或者用API自动转发都可能。

NodeBB 官方似乎对这个有兴趣：https://community.nodebb.org/topic/17117/what-s-next-after-v3/7 ，
而且另一边 Discourse（NodeBB 直接竞品） 甚至粗略的计划也有了：https://meta.discourse.org/t/federation-support-for-discourse/90921/87

ActivityPub 不是一个小东西，还要有更加充分的技术背景考量才行。（我只是听过这个名字，并不是太清楚它具体是啥）。不过既然 NodeBB 官方已经表现出兴趣了我们跟进官方实现就行