V2EX › ysmood 的所有回复 › 第 1 页 / 共 15 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10 ... 15

❮

❯

2025 年 12 月 25 日

回复了 jaydenWang 创建的主题 › 程序员 › React 缺失的“M”层：我开发了 Zenith，重塑完整的 Model

@jaydenWang 我意思就是人家都不想用 mobx 了改用更简单易扩展的 zustand 了，为啥还要退回你这种类似 mobx 的方案呢？

这几个库就是在解决相似的问题，只是设计哲学不一样而已，我觉得放在一起讨论是合适的。状态管理和 react 耦合，这占据这些库 90% 的要解决的问题，其他你说不同的地方的就是解决不到 10% 的问题而已。

2025 年 12 月 24 日

回复了 jaydenWang 创建的主题 › 程序员 › React 缺失的“M”层：我开发了 Zenith，重塑完整的 Model

@jaydenWang redux 很工程化，为什么大家最后大家都宁愿 zustand 呢？因为你是强制要求别人工程化，而不是循序渐进的工程化，好的架构是能让大家能从 0 开始循序渐进的工程化，stalo 就是践行这样的设计，它并不强调只有一个 global state ，而是你可以先从简单的 global state 入手然后逐渐拆分系统，这个 example 里都有。你 provider 就是中心化的表现，只要有持久化的状态就肯定会存在类似 context 的概念，这是 gc 的架构就注定无法逃脱的。只是在于如果合理的引导大家工程化才是重点，而不是上来就 push 一堆大部分时候用不到的概念在框架里。

从我个人经验来讲不符合循序渐进的框架，最终都很难成功。这和乐高为什么能火这么多年是一个道理。

2025 年 12 月 24 日

回复了 jaydenWang 创建的主题 › 程序员 › React 缺失的“M”层：我开发了 Zenith，重塑完整的 Model

@jaydenWang @XCFOX 我写了个更简单易用的 https://github.com/ysmood/stalo

其他的库对于 typescript 的支持比我这个要差很多。尤其是 zustand ，这是我主要开发 stalo 的原因。

这里有和 zustand 还有 valtio 等其他库的对比： https://github.com/ysmood/stalo/issues

甚至开发专用的 devtools 插件，甚至可以玩 time travel ，视频演示性能比 redux 快几个数量级: https://www.youtube.com/watch?v=DpQg0EDeTEc

可以自己开网页体验： https://stalo-examples.vercel.app/examples/Devtools.tsx

computed value 就是个伪命题，复杂的项目都会尽量少用，因为 debugging 可能会非常复杂，不复杂的项目就更用不到了。关于重复渲染的问题，通常是简单的 redundant model 反而容易 fine tune 和优化，如果大量使用 computed value ，很可能加大耦合反而难以优化。

你这个库还要依赖 context provider ，用起来非常麻烦，stalo 跨组建之间 share 状态更简单。

你甚至可以基于我这个库开发，这样你就可以直接利用我写的 devtools 了。你这个项目代码连一行测试都没有，一般稍微懂一点的开发者是不敢用的，我这个项目至少测试都是 100% coverage 。

2024 年 10 月 29 日

回复了 NerdHND 创建的主题 › React › Zustand 的文件组织?

我也是头疼 zustand 的文件组织和冗长代码，于是最近自己写了个库 stalo 。我写了个 todo app 用来演示如何将一个 store 分割成逻辑隔离的多个文件： https://github.com/ysmood/stalo/tree/main/examples/TodoApp

从目前我自己的使用来看，各项指标都由于 zustand ，我甚至用 stalo 写了个 devtools 来 debug stalo 自己： https://stalo-examples.vercel.app/examples/Devtools.tsx

2024 年 6 月 19 日

回复了 0o0O0o0O0o 创建的主题 › 分享创造 › vaultwarden 备份思路之再也不改版

@kuanat 可以试试这个，比 gpg 更简单方便 https://github.com/ysmood/whisper

2024 年 1 月 4 日

回复了 ysmood 创建的主题 › 分享创造 › 利用 github id 加密隐私数据（测试送 100 元红包）

@chaoschick 这种工具之所以存在就是因为现有的很多系统功能不全，且不愿意花时间改进，比如 V2EX 就没法私信，这个时候有这种工具就会方便点，你如果不用类似工具，请问 v 站里两个陌生人在不暴露自己隐私的情况下如何交换邮箱互加好友？你可能可以，但是会很麻烦

2024 年 1 月 4 日

回复了 ysmood 创建的主题 › 分享创造 › 利用 github id 加密隐私数据（测试送 100 元红包）

@chaoschick 你可以看看 age 这个工具 https://github.com/FiloSottile/age 被非常多的库依赖了，你可能不太能理解它的用途，但事实上用的人非常多。

2024 年 1 月 3 日

回复了 ysmood 创建的主题 › 分享创造 › 利用 github id 加密隐私数据（测试送 100 元红包）

> 第二个问题，似乎你没有理解第一个攻击例子的场景：A 要和 B 说话，B 选择去听任何人的话，M 达成的效果是 M 不知道 A 想说什么，但是让 B 以为 M 说了 A 本来要说的话。B 是用 M 的公钥验证的。

你都不在乎谁发给信息了如何防止中间人攻击？

> 通行的做法是归约，你的算法可以看作某种安全性的 KEM 和 CPA 安全的私钥加密和签名的复合，无法推出第一个例子下的安全性。

就和你说的一样，这不是 whisper 想要解决的问题，这更像是 ssl 之类的需要考虑的问题。使用 whisper 的人大大概率不会考虑中间人攻击的问题，所以 sign 是可选的否则我就设置成必选的了。

2024 年 1 月 3 日

回复了 ysmood 创建的主题 › 分享创造 › 利用 github id 加密隐私数据（测试送 100 元红包）

@Senorsen #22

> 谢谢回答，不过我的问题在于，只使用“加密”是不需要私钥的，只需要拉取 GitHub 上目标用户的公钥，因此无条件启动 agent 的行为比较怪。

多谢，这是个很好的建议，我把它改成只有需要的时候才启动好了。
加 sign 或者解密的时候都需要 passphrase ，非常常用。我建议是即使是发送的时候也加个 sign ，更安全。

2024 年 1 月 3 日

回复了 ysmood 创建的主题 › 分享创造 › 利用 github id 加密隐私数据（测试送 100 元红包）

@geelaw #25

> 但是这会导致没有选择超过 128 位密钥的意义，限制了最大安全性。

openssl 默认用的 128bit ，在 whisper 的使用场景已经够安全了，因为这个 aes key 只会被使用一次就扔了。我加了个选项： https://github.com/ysmood/whisper/blob/86d93ffbb3897d1739664da5597f6b85d1045be4/lib/piper/encodings.go#L74-L75

> 第二个问题，对密文签名只能保证密文“被谁同意”，不能保证明文来自于谁，也不能保证密文在加密结束之后没有被“有意义地修改过”，后者是选择密文安全性的要求。

whisper 没有这个问题，readme 里已经说明了 sign 验证需要显示声明发件人的 github id 用以验证，否则你就不在乎被篡改。你不可能再签名的，验证会失败。

> 除非收信人只收取某个特定的人（以签名所用的公钥识别）的信息（因此 M 重新签名不会被接受），否则上述场景可以成立。

和上一个问题一样。

> 但如果收信人只收取特定的人的信息，则没必要每次通信都用公钥加密。

这也不是安全问题，只是某种大部分人不在乎的性能优化，whisper 的使用场景是单次的无状态通信。

2024 年 1 月 3 日

回复了 LonnyWong 创建的主题 › 程序员 › 我把开源 README 又改成英文了

还是依赖了 ssh-agent 服务吗？也就是如果没装 ssh 就没法用 agent 吗？

2024 年 1 月 2 日

回复了 ysmood 创建的主题 › 分享创造 › 利用 github id 加密隐私数据（测试送 100 元红包）

@geelaw #24

> 你的第一段回复表明确实弄混了块长度和密钥长度，AES 的块长度永远是 128 位，密钥有三种长度。不存在“选择”块长度这种操作，因为没的可选。

我意思是保证不论使用什么长度的 secret ，最终都是使用 AES-128 ，这是 golang 的标准库规定的用法。抱歉没有很专业的表达我的意思，我这里并不在乎块的长度。所以我这个操作又安全风险吗？

> 第二段回复表明没理解什么是选择密文安全性。把公钥加密和 AES 以 OFB 模式（不是选择密文安全）结合时当然不可能期待选择密文安全性。

抱歉我理解错了你的意思，你意思就是信息可以被篡改吧？这个攻击又不可以破解具体内容。whisper 不是提供了 sign 吗，文档里最后有提到 sign 的用法，如果你觉得你的数据有被中间人篡改的风险，用 whisper 的 -s 参数就行了。

2024 年 1 月 2 日

回复了 ysmood 创建的主题 › 分享创造 › 利用 github id 加密隐私数据（测试送 100 元红包）

@Senorsen 感谢试用！

> ssh 密钥确实也是个问题

关于选哪个 ssh 密匙一般不存在问题，大部分人机子里都有。而且可以加冒号选择某个 ssh pub key ，比如 "@ysmood:abc"

> 这密文还挺长的

密文已经很短了，你看 gpg 生成的比这可能长几倍。同类工具这个应该是最短的。

> 请教下为啥需要一个 background agent ？

因为 private key 通常是一个文件，任何系统里的 app 都可以读取到这个文件，这很不安全。所以一般都会用一个 passphrase 加密这个 private key ，只有用的时候才解密到内存里使用，这样任何系统里的 app 都没法获取真正的 private key 。但这会引入一个新问题，每次都输入 passphrase 非常麻烦，所以一般加密工具都会提供一个 agent 来缓存 passphrase 到内存，比如 ssh-agent ，这样只有重启电脑的时候才需要再输入一次。

这是一个非常通用的技巧，Apple 的 Touch ID 也是这样的，只不过它用了一个专用 chip 来缓存，掉电了就得重新输入 passcode 。

2024 年 1 月 2 日

回复了 ysmood 创建的主题 › 分享创造 › 利用 github id 加密隐私数据（测试送 100 元红包）

@lambdaq 不用这么麻烦，这样就够了 https://github.com/ysmood.keys

2024 年 1 月 2 日

回复了 ysmood 创建的主题 › 分享创造 › 利用 github id 加密隐私数据（测试送 100 元红包）

@equationzhao 我试了下 warp 我也是 mac ，没有任何问题，可以正常输入 passphrase ，你用的是 zsh 吗？

可以通过

echo $0

来看用的什么 shell 。

2024 年 1 月 2 日

回复了 ysmood 创建的主题 › 分享创造 › 利用 github id 加密隐私数据（测试送 100 元红包）

抱歉订正下：公钥，不是公式

2024 年 1 月 2 日

回复了 ysmood 创建的主题 › 分享创造 › 利用 github id 加密隐私数据（测试送 100 元红包）

@galenzhao 很容易呀，那你就把第 1 个公式当成通用的公式呗，只需要把它的密钥拷贝到所有的机器上就够了。

就相当于你每台机子都要登微信才能用微信一样的道理，你至少要有一个密钥是所有的电脑上才都有的你才能方便别人给你发私信，不管你用什么工具都是一样的。

2024 年 1 月 2 日

回复了 ysmood 创建的主题 › 分享创造 › 利用 github id 加密隐私数据（测试送 100 元红包）

@geelaw 要说 whisper 代码里最有争议的地方，应该是 ed25519 转 ecdsa 的安全性问题。目前没有太好的办法，推荐加密还是用 ecdsa 比较好，ed25519 只用于签名。

https://github.com/ysmood/whisper/blob/0e43607cd36c869bdaa9a03f63701eb5603ffec3/lib/secure/key.go#L267

要是能帮忙把这个问题解决了那就厉害了。

2024 年 1 月 2 日

回复了 ysmood 创建的主题 › 分享创造 › 利用 github id 加密隐私数据（测试送 100 元红包）

@geelaw 我看了下 golang 的 rsa.EncryptOAEP 感觉也足够安全了，不太需要再做额外的优化了。

2024 年 1 月 2 日

回复了 ysmood 创建的主题 › 分享创造 › 利用 github id 加密隐私数据（测试送 100 元红包）

@galenzhao

> 不过像我这个有一堆公钥在的，不太好整

whisper 已经解决这个问题了，它可以自动选择密匙，也支持公钥过滤。原理在于它 embed 了公钥的 hash 到加密后的内容，你可以试试。

比如这是用你的第三个公钥加密的信息，你直接可以用 whisper 解密，不需要任何配置：

echo 'hi' | whisper -b -e @galenzhao:IfQaAz

AQABAba9zT8BAYAD0JJoTb40bb5vxJshk9cU9p8EzsqDpnGMcEnbAE2ppJjoXsZcLyyiEuhb96G4yDCiU5CCOWPUANLxWK2ZMzWxc+y5Sa0XIy44Z/kEdu+OhZ+sYDuzhHAF1Bptjof5eFRDAx08Tl63en15/SDHB3WeGiQZhCTlgz44wUPZ6qcD5mvJhkgjpDlvAwZuUTuRxlDrEvAGjo03DTlu1xqUk8HhU2TtrzI4Zt86ymNc/JNtd8MQ8qi6FVanGIQATUZ7URJH3i22NmCN6NKek28iXCrOgtva53scJHuDbkfYrkEJBJl7WOdiHeX8jbvR/0Y3oJML6/kFgdYwi6t93zYwwIsKaT9hYHsxh0EvPODn9E9lHyYN142TwhnUllz8vd+dIR53YEXJfYjhoStpbVrpQ5SQHswRlc5F/kV5FiKWMKKTggRRk5FNEPIycuyAQiGyqPT4HVZrCFOOgxPcDxYWbsskHaZAy4zUxHRfpvAVRfgza+m5sQHQUpn6TiE5Q+ucf6d5+AEWbCxMuWSyJ8qwMSQlbs9K/v14

1 2 3 4 5 6 7 8 9 10 ... 15

❮

❯