开个新坑，分享我对家用云服务的心得和思考。 网上常用 NAS、HomeServer、HomeLab 来称呼这类产品，我更愿意叫它家用云服务——它聚焦于个人与小团体的数字化体验，区别于企业级的公有云和私有云。 2021年回老家时，我临时起意买了个黑盒子，一路拎着进家门，从此一发不可收拾。5年间，保守估计折腾了1000小时，大致相当于我花在跑步上的时间，成了我的两大业余爱好之一。如今我日常维护着2台NAS，加上主机、Mac Mini，以及若干网关路由和VPS。 自托管的代价：从1000小时到"无人值守" 为了更直观理解本文的主旨，我先分享一下这1000小时折腾的"成果"，也算个人碎碎念。主要围绕网络、安全、应用三个维度展开。 网络：复杂的冗余方案 为了实现"无人值守"，我构建了一套复杂的冗余网络： * Tailscale（自建中继）和 WireGuard 在不同场景下切换使用 * 蒲公英组网作为备用，
我并不爱记笔记，但是要学习的多了，就不得不：打开、写、保存。 记笔记效率太低，哪怕只是复制粘贴，也得花时间整理格式；技术知识又很容易过时；而且我几乎从不回看笔记，笔记只是在记录的哪一刻稍微加深点记忆，之后就再也不打开了。反倒是对记过的知识点又经常搜资料、查文档，感觉效率更高，也相当于复习。 一、AI出现之后，学习链路被彻底改写 生成式AI改变了这一切。不再需要频繁用搜索引擎，不再需要盯着官方文档逐页翻，当然，特别新的偶尔还得手动查一下，至少对重要的信息要自己验证一下。 因为LLM压缩了公共知识，它还能调用工具，比如搜索工具、MCP工具、CLI工具。还有一个常被忽略的点：LLM的注意力机制和人类非常不同。跟人对话，一连串问题甭管说得多重要，对方大概率只回最后一个；而LLM能一次性把所有问题都答全，除非上下文长到几十万字，出错概率才会明显上升。这种特性天然适合高效学习和记录，因为学习本来就是由一连串问题或大纲扩展而成。 那么，还需要记笔记吗？理论上，LLM回答的都是公共知识（除非导入私有知识库），确实没必要记——没记住？再问一遍就行。但AI有幻觉问题，
前言 在 Docker 容器化部署中，Permission denied（权限拒绝）是最常见的障碍之一。无论是容器启动失败，还是宿主机无法修改挂载的数据文件，其本质往往归结为宿主机与容器内部用户身份的不对等。 本文将深入剖析 Docker 权限管理的底层机制，提供从架构设计到具体配置的完整解决方案，并覆盖 SELinux、NAS ACL、Docker Volume 等特殊场景的处理策略。 ⚠️ 适用环境说明 本文主要针对 原生 Linux 环境（包括 Ubuntu/CentOS 服务器、群晖 DSM、威联通、Unraid 等）。 对于 Windows 或 macOS 上的 Docker Desktop 用户，由于虚拟化层自动处理了文件所有权映射，通常无需进行复杂的权限配置。 1. 核心机制：Linux 内核的
我已经使用matrix很长时间了，为它做了几个项目，成了重度用户和开发者，也加入了一些房间讨论。最近一次交流不太愉快，却也促使我转变思维，不再聚焦于社区和我自身的需求，而是从外部视角获得清晰的观点！这应该是我最后一篇专门写Matrix的博文，特别资讯专栏（如脚本更新）仍会通过邮件和房间推送。对于这篇文章，欢迎不同看法。 “客户端实现”：一个看似美好却充满陷阱的提议 在Matrix生态中，当讨论新功能（例如“联系人别名”）缺失时，一个常见的观点是：协议本身是极简、稳定的骨架并提供了一定的扩展性（自定义事件），功能创新应该由客户端在骨架之外自行实现。 这个观点在技术上“正确”，但它回避了作为一个“生态”在实践中要解决的核心问题。依赖客户端自行实现，隐藏着三个陷阱： 1. 体验的割裂与标准化的必要性 Matrix的核心价值在于联邦与互操作性。一个功能（比如“投票”）如果只在一个客户端上实现，那它对生态而言几乎是无用的、体验是分裂的。为了让其他客户端也能参与投票，这个功能最终还是需要通过MSC（Matrix Spec Change，协议规范变更
一、对联邦网络的错误幻想 在很长一段时间里，我（以及许多人）对Matrix这样的联邦网络抱有极大的热情。我们渴望一个开放、自主、去中心化的“下一代社交平台”。我曾深入研究它，寻找并设想各种创新的应用，试图把它打造成一个更好的“微博”或“微信”。 然而，这些尝试“低效且低价值”，理由和许多人的感受一样： * 没有“流量”： 作为一个内容创作者，在上面得不到反馈。没有读者增长，没有互动，没有收益。 * 没有“效率”： 作为一个内容消费者，找不到好内容。没有算法推荐，发现机制原始，信息密度极低。 * 没有“连接”： 作为一个网络平民，早期互联网论坛和聊天群那种田园牧歌式的氛围不复存在，只有边缘化、匿名化的流动ID。 联邦网络如果是为了模仿或替代主流平台，无疑是失败的，需要换个角度。 二、为什么觉得Matrix“没用”？ 在找到正确的方向之前，先绕开那些让我们感到失望的“坑”。 坑1：
近期 Synapse 发布了 1.141.0 (2025-10-29) 版本，此版本的 Docker 镜像已基于 Debian trixie 和 Python 3.13。 🚨 问题所在 这次底层系统的更新，导致了 Python 软件包的安装路径发生了变化（从 python3.12 变为 python3.13）。 如果您之前使用我博客的中文搜索脚本，通过 docker-compose.yml 中的 volumes 来硬编码挂载自定义 Python 脚本，您的 Synapse 服务在更新后将无法启动。其他外挂的python模块同理，例如shared_secret_authenticator（网桥认证模块）， 旧的、已失效的配置如下所示：
oEmbed 是一种让第三方网站通过 URL 嵌入外部内容（如视频、图片或网页摘要）的格式。它包含两方： * 消费者（如社交媒体）向 提供者（如 YouTube）请求嵌入内容； * 提供者 返回 JSON/XML 格式的数据，包括媒体、标题、摘要等信息，供消费者直接展示。 Matrix/Synapse 支持通过 oEmbed 协议为消息中的链接生成丰富的图文预览。虽然 Synapse 内置了一套规则，只有但可能对某些网站的支持不佳或显示信息不够全面。这时，我们可以通过引入第三方的 oEmbed provider 列表（如 https://oembed.com/providers.json）来增强此功能。 但在配置过程中，可能会遇到一些问题，以下是解决方案和已知限制的总结。 配置中的常见问题 在使用
本教程提供两种在 Matrix 中实现消息自动删除的方法。方案一需要服务器管理员权限，效果更底层；方案二通过机器人实现，只需房间管理员权限即可。 方案一：通过服务器 Retention 功能实现 (需服务器权限) 此方案通过配置服务器底层的数据保留策略，让服务器从数据库层面定期清除过期消息。 第一部分：服务器端配置（管理员操作） 1. 编辑配置文件: 打开你的 Synapse 服务器的 homeserver.yaml 配置文件。 2. 添加 retention 配置: 参考以下配置在文件中添加或修改： # 消息保留策略，存在于房间级别，遵循MSC1763 retention: # 开启 retention 功能 enabled: true # 配置清理任务，定期从数据库删除过期事件 purge_jobs: # 这个任务每一小时运行一次，清理最长生命周期小于等于3天的消息 - longest_max_lifetime: 3d inte
交流群：博客右上角"账号-联系支持服务"，发送邮件获取Matrix房间邀请。 服务器要求 3种需求： 1. 只本地聊天 性能要求：2核2G，25G SSD。 网络要求：可拉取Docker Hub镜像和GitHub仓库。 推荐搭建环境：家庭NAS。 2. 异地使用+少数联邦 性能要求：2核4G，50G SSD。 网络要求：公网IPv4（用内网穿透也行）。可拉取Docker Hub镜像和GitHub仓库。联邦网络需要能访问指定域名。 推荐搭建环境：家庭NAS（具有透明代理环境）或海外VPS。 3. 全球无障碍通信 性能要求：至少2核4G，50G SSD。如果有大房间聊天和保存大量媒体文件的需求，则推荐2T以上 SSD，或者一台独立的数据库服务器和S3存储盘。 网络要求：可访问全球互联网的服务器
花了很多时间解决家庭路由问题。 最一般的用途上，电信运营商提供光猫，光猫兼路由功能，上门安装的师傅包办了，稍微大户一点的家庭，会需要路由器，乃至AP、交换机，这些产品都是出厂配置好了的，照着说明书几步就搞定。 难在想要自定义路由，想要有软件的功能。 我实际需求中得路由器上解决的，包括并不限于： 1. 网络中转和分流 2. 异地组网 3. 网络监控和上网保护 4. 游戏加速器 5. 网络容灾（这个范围很广，例如路由器一级的ddns、内网穿透） 不在路由上解决行不行？可以，但通常更复杂，使用起来更麻烦，也有更多不可预知的故障。举例来说：网络中转和异地组网，这些本质上要接管全局的网关流量，如果不用路由器上的透明化方案，那得在每个设备上都安装客户端（如果有相应软件的话），并且有些功能可能无法使用，例如24小时在线的服务，这很重要，例如家里的NAS服务器掉线了，在外地可以登录到路由器检查情况，并重新唤醒设备。 既然网关上的软件功能必不可少，针对不同的路由拓扑又产生了很多不同的实施方案，这里不探讨各种方案，而是直接给出我认为目前家庭（包括个人）
交流群：博客右上角"账号-联系支持服务"，发送邮件获取Matrix房间邀请。 Matrix 通信网络协议最常用的客户端 Element 过去一直使用免费的 Jitsi 作为群组视频会议组件。一对一音视频通话则相对复杂：如果双方客户端具有公网 IP，则可以建立点对点连接；否则需要通话发起方的服务端托管 TURN 服务来绕过网络地址转换 (NAT)，中继 WebRTC 连接。 现在这一情况已得到改善。Elment.io 开源了原生的 Matrix 视频会议应用程序 element-call。它的优势在于端到端加密、流畅性，以及基于 LiveKit 的可扩展后端；缺点是与 Jitsi 相比功能仍较为简陋，例如缺少背景虚化、主持功能等。 Element Call 客户端组件现已内置于 Element 桌面和网页端，并在新一代移动端 Element X
更新时间：2023年3月5日20点32分 除非 Ghost 有你不可替代的功能需求，或者喜欢上手高难度，否则我建议你放弃。 备份和更新 Docker 版不支持完整的 Ghost CLI，例如通过命令行进行备份，备份参考文档：如何重新安装幽灵。 Docker容器更新办法： 一种方式是通过 Watchtower 自动更新，比较省事，但是可能会出问题，博客掉线了可能都不知道。 另一种方式是手动更新： * 初始搭建时选择 ghost:latest 这个名称的镜像。 * 更新只需重新下载，镜像同名但是最新版本，新镜像将会替换旧镜像。 * 然后将正在运行的 Ghost 容器复制一份。 * 关闭旧容器并删除旧容器上的端口映射。 * 启动新镜像的容器并选择复制旧容器的设置和数据，重新映射端口。 * 博客已经运行在新容器上，数据没有损失。 * 运行一段时间后再决定是否删除旧容器和镜像。这种更新方式比较安全。 扩展阅读：如何更新群晖Synology的Docker容器_哔哩哔哩_bilibili 问题1：每次系统重启或容器更新时 Ghost
更新时间：2023年8月16日06点59分 Ghost大概是最佳的Newsletter[1]自托管方案，但一来它的学习与搭建成本比较高（参考我的#Ghost 系列博文），二来在Newsletter方面也有诸多限制：不支持SMTP，只支持Mailgun的API。 假设你拥有可用于批量投递的企业邮箱（从知名品牌服务商那儿获取的个人邮箱和非独立公网环境下自建的邮箱并不适合用来发送批量邮件——这应该成为常识），希望进行Newsletter形式的内容创作，Listmonk可以用作Ghost的补充工具。或者你并不需要一个博客，而是将listmonk单独使用——提供给访客一个简单的订阅表单，文章不发布于网站，只从邮件推送，此外也支持短信、手机通知，这个demo可以体验完整的功能，这里主要介绍如何安装。 官方文档介绍的是用docker-compose安装，默认配置也将安装Postgres DB，Postgres是必须的，许多Docker项目都依赖Postgres数据库，我建议独立安装，让许多服务连接同一个容器，安装教程参考postgres - Official Image | Docke