#zh_CN互联网是没有记忆的

刘思齐：说到这儿，我有几句话特别想说出来。我住院的时候有个同事去看我，告诉我网上有人写毛岸英是因为做鸡蛋炒饭而暴露目标的。这些毫无根据、不负责任的言论让我非常难受，因为我……我就想到，一个烈士献出他生命的时候只有28岁，他在献出自己生命前，遭受了人类所能忍受的最痛苦的死亡方式，他是活活烧死的，除了古代的凌迟，没有再痛苦的了。网上究竟是什么人，可以对这样一个烈士说出那种话来？他们的心得是多么冷酷？鸡蛋炒饭！朝鲜战场那么艰苦，哪里来的鸡蛋，哪里来的大米，那时候他们吃的是没有破壳的高粱米，排出来还是一粒粒的。

  本文摘自《北京晚报》2010年10月31日第12版，作者：金力维，原题：《刘思齐回忆一次痛苦一次》

http://cul.sohu.com/20101101/n276885848.shtml

#zh_CN互联网就算恢复了记忆也要为自己开脱

在2010年《毛岸英》电视剧播出前，已经80多岁的毛岸英遗孀刘思齐接受了记者的采访。年过古稀的老人愤怒的指出：“网上说毛岸英是因为做蛋炒饭而暴露目标的，一位烈士献出生命的时候只有28岁，而且还是被活活烧死的，他们居然能说出这种话？他们的心是有多么冷酷？”

不过，在那个年代，一个古稀老人的辟谣没什么用，那些公知在之后的网络时代，更加疯狂的对毛岸英烈士进行造谣、污蔑，并“成功”编造出一个“蛋炒饭”，专门用以对毛岸英烈士的侮辱。

所以，刻意选择在毛岸英烈士的生辰与牺牲的日子发布所谓的“蛋炒饭”，基本上就是在通过这种隐秘的方式对烈士进行侮辱。

http://m.szhgh.com/show.php?classid=61&id=282424 (原载于网易的原文已删)

如何和绒绒交朋友
https://twitter.com/morty5678/status/1454321930719272960

Telegram: 何不食德卞？

守护中国地方（山陰山陽地方）是吧😅

Telegram 最近的一次更新让用户可以「躲在频道后面」在群组里发送消息了，这使得某些针对群组中的频道自动转发消息（下称「绑定频道消息」）作出响应的 bot，可能对躲在频道后面的用户发的频道消息（下称「躲猫猫频道消息」）也作出响应。
这是由于 Telegram 毫无预警地打破了自己的 backward compatibility （见评论区），使得群组里的来自 777000 的消息不再一定是绑定频道消息，而也有可能是躲猫猫频道消息了。Telegram 已经更新了 HTTP Bot API，为 Message 增加了 is_automatic_forward 字段，但你用的库未必已经更新，在此提供一个 workaround：

1. 通过 from 、 forward_from_chat 和 forward_from 初步辨别：已总结至 https://t.me/tgsucks/2056 。绑定频道消息一定 from 777000 ，同时要么有 forward_from_chat ，要么有 forward_from ，这是一个充分不必要条件。因此可以筛掉同时不存在 forward_from_chat 和 forward_from 的 from 777000 的消息，它们一定不是绑定频道消息，余下的消息进入进一步筛选。

2. 使用 getChat(chat_id) 方法，可以获得群组绑定的频道 id，与 sender_chat 的 id 比较即可。

实际上，某些自作聪明的 "anti-spam" bot 遇到带 sender_chat 的消息就删除的做法是很不可取的，它们除了按照预期把躲猫猫频道消息删掉以外，还会把绑定频道消息和群组匿名管理员消息也删掉。我就不评价一刀切删掉所有躲猫猫消息是好还是不好了，我是不会去用或者写这种 bot 的。（两条腿坏，四条腿好；躲猫猫也是猫，也是四条腿）

因为 AWS 绝赞爆炸中，虽已对 @comments_helper_bot 应用了 workaround，但暂时无法部署🤒迁移到另一个 region 部署上去了，现在它能够正确地回复所有绑定频道消息，同时不会错误地回复其他消息。（注意：这个 bot 为频道评论区提供投票和禁止加群功能，但不提供对躲猫猫频道消息的任何处理，包括但不限于：删除、封禁频道等）

TL;DR
筛除躲猫猫频道消息:

Message.from.id == 777000 && Message.sender_chat.id != getChat(group_id).linked_chat_id 

speedup:

Message.from.id == 777000 && 

(!Message.forward_from_chat && !Message.forward_from) || Message.sender_chat.id != getChat(group_id).linked_chat_id

几日前，Telegram 已经修正了群组里的频道消息对于 HTTP Bot API 而言全部来自于服务账号 777000 的问题。现在，777000 的行为又和过去一样了（自动转发绑定的频道的消息），而躲猫猫频道消息则改为使用机器人账号 @Channel_Bot 发送。可见 Telegram 终于意识到毫无预警地打破自己承诺过的 backward compatibility [1] 是多么糟糕的一件事。

这么一来，Bot API 5.5 新加入的 Message.is_automatic_forward 已经不再是必要的了 [2] 。

有趣的是，@Channel_Bot 是个早已存在的机器人账号。6 年前，Channel 推出，Telegram 设置了这个特殊的账号用于为未支持 Channel 的旧版本客户端填充消息来源。如今竟能焕发第二春，也是十分奇妙。

[1]: 这个 backward compatibility 可以作两层理解。第一层见下一条消息，第二层则是对已经存在的 bot 的 backward compatibility 。在 Telegram 在 HTTP Bot API 5.0 的更新日志里正式宣布之前，它已经这么使用 777000 很久了，并且 bot 根本不能通过 HTTP Bot API 查询群组绑定的频道（到了 5.0 才可以查询），因而在 bot 开发者中已经形成了一种习惯乃至事实标准。
[2]: 严格说来，777000 的用途不止是作为绑定频道消息的占位账号，它在群组以外也有别的用途，但在正常情况下在群组里确实只有一个用途。另外，个人认为 Message.is_automatic_forward 的加入可能只是为了减轻 bot 和服务器负担。在当时 777000 被混用，如果没有它，bot 就不得不通过 getChat(user_id) 方法取得绑定频道的 id 以比较，服务器需要为这个方法返回大量的信息。

上面提到，@Channel_Bot 在 HTTP Bot API （以下简称 Bot API）和客户端（使用 MTProto API ，官方称为 Telegram API）上都被用作占位账号，但两者又很不一样。

Bot API 没有办法得知 client 是新或旧，因此每次升级都必须尽最大努力保持向后兼容性，由此出现了很多冗余、累赘的设计。由于 Message.from 最初被定义为只能是 User 且不能为空，后来才不得不引入了 777000 , @Channel_Bot , @GroupAnonymousBot 来占位，除非再引入 breaking change，它们将长期续命下去。
MTProto API 定义了 layer ，更新 API 就是增加一层新的 layer [1]。client 在启动时将告知 server 自己所支持的 layer 号。因此，只需要在 server 端根据 client 的 layer 为其「量体裁衣」，就可提供绝大部分的向后兼容性。所以在新的 layer 里引入 breaking change 就不是那么大的问题了。上述占位账号在客户端 layer 过旧的时候会出现，但一旦更新了客户端，就可以正常显示了。

以下为私货：
实际上，Bot API 做的唯一一件事就是充当 bot 和 MTProto API 之间的桥梁，并且还是个不完整的、松松垮垮的桥梁。可能是迫于服务器压力及饱受诟病的延迟问题，Bot API 已经开源，现在任何人都可以搭建自己的 Bot API ，且可以免受官方实例的一些限制。
但…为什么要让中间商赚差价呢？除非对 webhook 有需求，或者喜爱的语言不存在好用的 MTProto 库，强烈推荐弃用 Bot API ，转而使用 MTProto API ，以获得更佳的性能 [2]、更短的响应时间 [3]、更全面的功能 [4]，及节省在前者身上 deal with bullshit legacy 的时间。

[1]: 实际上不全是，Telegram 有时也会直接在最新的 layer 上直接修订，而不是引入新 layer
[2]: 见 Advantages of MTProto over Bot API
[3]: 直接连接至 bot 所在 DC。官方提供的 Bot API 设置于 DC2 （位于荷兰），而 bot 所在的 DC 由 owner 所在的 DC 决定。Bot API 由于固有缺陷本身已经不快，非 DC2 账户创建的 bot 将在网络延迟上有更大的 debuff。想知道使用 MTProto API 的 bot 延迟能有多低？Try: @RSStT_Bot
[4]: 见 MTProto vs HTTP Bot API

zh-M$ 能反向的得地不分我是没想到的

本次拉稀速度：
1.5k 字 / h

（没有 copy&paste 或者使用 Copilot 填充任何内容）