给自己定个周期性目标，英文或者拼音 Capital@Case
既记住了密码，又记住了目标

在？为什么要用猜话器不用输入法？

可是 diff 本来就能 -r 啊

当我需要的歌连 spotify 都没有的时候，我就放弃了在线听歌

@w99wen 彩虹表不是对照表，而是一个依赖于特定的哈希函数 hash 和随意指定的、反转了定义域和目标域的函数（实质上是另一种 hash，不过通常生成的是变长字符串） rehash 构造的简化对照表，它的结构和 hash 强对应，

彩虹表就算你在 6 位数字上加一位数字的盐，因为哈希算法被改变 new_hash = d=>hash(salt+d)，导致整个彩虹表不可用，但对照表的话刚开始就构造 7 位对照表的话还是可以使用的。
这就是为什么需要每个用户独立生成盐，否则还是可以用彩虹表。

@fumichael 数据库加盐加密主要是为了防止彩虹表和哈希字典的。
人们早就知道 'E10ADC3949BA59ABBE56E057F20F883E' = md5('123456')
但如果你采用加盐的方法，你看到 'hellomyzebra,yestheyaresocute:' '3A64C835017B142A97B5ADAECF249673' 又怎么知道密码是多少？
没盐的情况下，你可以直接 select * from users where passhash = 'E10ADC3949BA59ABBE56E057F20F883E' 得到这些人密码是 '123456'，甚至给一个哈希字典能够直接 select users.*, hashdict.hashee as password from users left join hashdict on users.passhash=hashdict.hashed 取出所有弱密码，整个耗时不过几秒。
用上彩虹表的话 20 位以下密码也花不了多久。

但加盐首先直接破坏彩虹表，其次弱密码爆破也需要很久，脱裤后有足够久的时间告警所有用户改密码了。

数据库中更标准的是采用 bcrypt 等方式，单密码校验需要 1 秒（可调参使得时间更长），简单 6 位纯数字密码，数据空间达 100 万，就是十几天，还多半不会命中。

@l4ever get 不是 http ？没太明白

但是其实还要担心一点：现在大部分服务器是运行在 VPS 上的，实际上如果过程中以明文存储在内存上，如果 VPS 提供商扫描内存的话是可以知道密码的。试问在座有几个人会对自己服务器上传入的数据在 HTTP 层面先做随机化分布？（即 SSL/TLS 层解密后在内存位置是打乱的）
Cookie 的另一个问题就是反授权时 token 之流方便一点，存用户名密码就需要重置密码了。

@mrdemonson 数据库加密并不能防运维和开发，Facebook 前车之鉴，会把明文密码打 log

@cheeto 所有用户数据在客户端加解密，服务器不存储任何形式的密码（连加盐版本也不存储），参考 Mega、Lastpass、ProtonMail 等，但相应的有如下弊端：
1、密码忘记不能找回账号内数据。你可以找回账号，但找回的只会是一个空账号，因为里面的数据只能靠之前的密码解密；唯一的解救手段是提供一个 Key 文件可以解密内容，但无法得到原密码，所以可以用 Key 文件找回之前的数据，但这一过程会清楚账号数据，所以拿到 Key 去拿别人账号必然被发现。
2、不符合中华人民共和国反恐怖主义法的需要。

Chromium 里用了黑白名单叫法被微软提出来了还不吃一堑，长一智？

@icris #293 生态系统割裂啊，fetch 是只要有（完整？）数据回来，就是走 then 的，只有连 status code 都没有才是 catch。

@icris 举些例子：（下面不那么符合 .d.ts ）
明示结束：
Interface T {id:string, name:string, telno?:string, addr?:string}
type TList = ['start'?, ...T[], 'end'?]
类似 Twitter 的 partial list：
type idx = string
type PartialList = {items: Map<idx, T>, uses: idx[]}
注意上述 items 甚至可以屏蔽部分对象不再传输一遍，而以 uses 自历史传输中取出。
另外，其实这个做法 HTTP/2 能够非常高效地支持，只要把这些以 RESTful 的形式拆开传输，先传 uses 然后客户端可以 reset 掉已经传输过的流。

——

然后，下面两个是包含关系，
Error | { data:T } < { code?:number, msg?: string, data: T }
我特地分离出来是可以写个 function(obj:APIResponseBodyParsedObject):obj is Error 和 ...:obj is Result 的判断，这样就可以无缝切入函数式的 Left|Right 的错误处理思想（一切对 Left 的运算皆返回 Left 本身，而 Right 则返回对 Right 里面的数据处理后再封装成 monad 的 Right ），虽然其实 JavaScript 内没有这个机制。
（ BTW 你写的似乎不是 .d.ts ，或者你想表达的正是恰包含一个空对象 {} 的数组）

@icris 列表的结束应该有结束指示器，类似 StopIteration，而不是用另外的工具（如状态码、业务代码）表示
当然这已经是现代语言思维的收束和 JSON 的限制了，实质上对于 partial list，没有触及边界的情况应该返回开界的，并且带有 index 范围，并且可以对同一个 list 的多个 part 进行简单、无错、无序的合并的。同时一个无限延伸的数组（比如推文）同样可以用右侧永远不闭合的 list 来表达。结果 Twitter API 就变成现在这个模样了，Dict[TweetId, TweetContent]。
这些语言不是为了分布式系统设计的，更不用提连为此设计的 Erlang 都不够适合分布式系统（因为用的人少没有经过充分的实践）。结果 MapReduce 啥的反而符合，但本该采用现有编程语言的（而不是设计一个 DSL ），本该写个 Python 或者 Java 或者 Lua 都能直接编译成 MapReduce 操作的。

@shoaly 中间商的作用：让上游生产者的资金得到迅速回流以支持进一步的生产。
而主观价值理论指出，有作用（需求）的就有价值，所以中间商赚差价是必然的，且能提供益处。

@wolfie 既然你不笑，那么你还能当 roast，你到底有没有被 amuse 啊？
把小丑当幽默？

ps 当一个人看到某个观点变得语无伦次，潜意识里说的可能是自己。