POLICR · 更新通知


Гео и язык канала: Китай, Китайский
Категория: не указана


收取来自 @policr_bot@policr_mini_bot 的功能更新和重要通知。
社区交流群: https://mini.telestd.me/community

Связанные каналы

Гео и язык канала
Китай, Китайский
Категория
не указана
Статистика
Фильтр публикаций


Видео недоступно для предпросмотра
Смотреть в Telegram
手机访问控制台的样子


Policr Mini 上线了新的管理后台:控制台

控制台是用于替代旧有后台的新功能管理页面,私聊机器人发送 /console 命令访问。相关更新详情:https://blog.gramlabs.org/posts/policr-mini-updates-2024-04-05.html

另外提及一下,目前 Policr Mini 的服务器运行压力非常大,尤其在内存占用上。已经有些不稳定。现阶段的理想服务器是 Hetzner 的 ARM64 架构 8核/16GB 服务器,但是没有途径购买(Hetzner 有很严格的新用户审核)。

如果你有途径欢迎联系我。如果有人赞助那就更好了,我们会把您的产品/网站/公司放在赞助商的位置(但只接受长久持续的服务器赞助)。


针对最近的热门游戏《幻兽帕鲁》,我们开发了辅助机器人。它目前可以查询最短配种路径,此功能并非配种关系的简单查询(并不是配种表的 Ctrl + F)。欢迎体验。

详情请阅读我们的博客文章:https://blog.gramlabs.org/posts/palworld-bot-tutorial.html


_albums-20240111-735.zip
8.7Мб
我们对验证资源生成器 mini-assets-gen 进行了增强,这是发布的最新修复版验证资源。

新的生成器支持「居中剪裁」机制,和网格验证配合,避免图片被拉伸。现在的网格验证图片拉伸问题已不存在了。

详情参考博客文章:https://blog.gramlabs.org/posts/mini-assets-updates-2024-01-11.html


所有累积更新已上线并稳定运行两天,期间有一些修复和重启,但目前不会再变动。

对于自建用户,稳定版的标签是 20240107 ,只有稳定版提供 arm64 支持。本地部署 Bot API 需要搭配我们发布的镜像使用:https://blog.gramlabs.org/posts/our-telegram-bot-api-image.html

本频道将在下次更新上线前夕发布新内容(更新说明中包含下次更新预告)。


_albums-20240104-710.zip
9.9Мб
因为有图片重写机制的存在,我们可以放心共享图片验证资源。这个压缩包包含了 710 张图片,可直接上传。

后续我们会发布更多图片的版本(我们有十几万张已分类图片,但缺乏筛选)。

别忘了阅读更新内容


2024-01-01 更新说明

新的一年大家好,Policr Mini 累积了半年的更新终于准备上线了。值得注意的更新包括:

1. 新部署模型,可以让机器人响应速度达到最快。
2. 网格验证,早期预告过的新验证模式。
3. 图片重写机制,让验证资源的收集变得无意义,提高图片验证安全性。
4. ARM64 架构支持,将机器人部署于树莓派等嵌入式 Linux 设备,Oracle Ampere A1 和 AWS Graviton 等 ARM64 架构的云服务器,甚至是你的 OpenWrt 路由器上。
5. 等其它变化

我们建立了专门的博客来记录这些变化,请阅读完整文章:https://blog.gramlabs.org/posts/policr-mini-updates-2024-01-01.html

官方实例将在凌晨前上线此次更新,同时期待更多用户在官方上线前部署这次的版本。请等待 CI 服务器构建完成:https://multiarch-ci.hentioe.dev/repos/6


新的验证模式:网格验证

网格验证的每一张图都是动态生成的,模仿 Google reCAPTCHA 让用户在多个图片中选择某一类图片,具有更高的破解难度。且网格验证是复用图片验证资源,同一个验证资源更新可同时改进两种验证效果。

网格验证在未来将取代单张图片识别的「图片验证」成为默认模式

由于图片是动态生成的,不存在被人收集全部资源的可能性。此模式应用后,将公布官方实例的图片验证资源,并经常更新。

注意:网格验证已在开发分支完整实现,但并没有合并到主分支。当前官方实例基于主分支代码,所以它暂时没有此模式。


升级到最新的数据库版本(PostgreSQL 16)

最近,知名的开源数据库 PostgreSQL 正式发布了 16 版本,本项目也紧跟步伐升级了许久未变动的数据库大版本。通过此文档升级你的数据库:升级到 PostgreSQL 16 版本

在本消息发出前不久,Policr Mini 已使用最新的 16 版 PostgreSQL 数据库,一切良好。

一些预告:由于开发者手头有更重要的事情,项目许久未有功能性更新。有许多新的构思,例如多选验证(选择并提交多个答案),动态生成组合图片(将 9 个图片合并成一张)并判断包含的事物或方向等。直到开发者恢复自由,本项目将迎来这些更新。


使用 /embarrass_member 命令重新验证群成员

在最近的更新中新增了一个叫做 /embarrass_member 的命令,使用此命令回复任意群成员的消息即可重新验证他。

一般来讲,会有一些原因需要重新验证群成员。如群成员疑似是能发言的人机、不符合入群门槛等。重新验证某个群成员时,最好是在他刚发言的时候,如果从历史消息中回复此命令会出现群成员不在线,错过验证的情况。

此命令对机器人使用是无意义的,对管理员也是没用的(管理员之间无法使用此命令斗法)。


最近的更新

这里是一些小更新,它们不重要,你可以跳过阅读。但不要错过后半部分。

- 通过后台切换验证模式时,添加了一些检查。当切换到自定义验证并保存时,若不存在验证问答内容,保存会失败并提醒添加自定义回答。

- 通过后台添加自定义回答内容后,会自动切换到自定义验证模式。这是因为有很多人添加了内容后,不知道要手动切换,导致一直未生效。

- 删除最后一个自定义回答后,会自动切换到系统默认的验证模式。避免没有自定义回答数据,但仍处于自定义验证模式。

- 处于自定义模式时,因缺少回答内容生成验证数据失败了,会自动将验证模式切换为系统默认,并在群内通知。这种自动纠错机制的添加是因为此前缺少这方面的检查,而很多群在删除自定义问答内容后,不主动切换验证模式,导致很多不正确的设置产生。

上面的更新只是一些小的变化,一些机制上的完善,一些检查。下面介绍的是此次相当重量级的更新。

基于 Approve new members 的验证

现在 Policr Mini 可以在启用 「Approve new members」的群组中完成验证工作了!

群组的设置选项「Approve new members」在不同的语言包中翻译可能不同,按照字面理解就是「批准新成员」的意思。启用此选项后,用户将不能直接进入群组,而是发送一个加群申请。管理员可以批准或拒绝加群,在批准之前用户并没有进入群组。所以此选项可以杜绝用户先加群后验证这种机制上的缺陷,可以从根源上避免因机器人延迟导致一些广告帐号在被限制发言前已将内容发出。

启用 Approve new members 有两种途径。对于公开群,可以直接启用。对于私有群,可以创建私有链接,编辑链接,然后启用。并且私有群可以存在不启用 Approve new members 的链接和启用 Approve new members 的链接。当私有群的多个链接具有不同选项时,用户从某些链接可以直接进入,从某些链接则需要批准。对于 Policr Mini 而言,可以同时应对这两种场合,维护不同的入口消息,在一个群中保持两种运作机制。

基本原理:在 Policr Mini 的实现中,将启用 Approve new members 选项的群(或链接)视为一种来源 (join_request),未启用的视为另一种来源 (joined)。面对不同的来源,会有不同的工作机理,但基本共享大多数代码和逻辑,使表面行为保持一致。

来源转换:在 Policr Mini 的设计中,同一个用户反复退出和加入,会复用同一个未完成的验证(而不是产生多个验证)。当用户从 joined 来源加入后退群,然后从 join_request 来源申请加入。此时被复用的验证将会进行转换。这种转换不仅仅是更新来源数据,还会有一些必要的动作。如 joined 来源的用户会直接进群,此时他若退出后从 join_request 来源申请加入,机器人会解除他的权限限制(从之前的 joined 来源加群时被限制了权限),因为 join_request 来源的验证通过后仅仅是批准进群,不会涉及权限变动。为了保证不同来源的转换和兼容,需要一些额外的动作。这种来源转换也可以反过来。

击杀策略:从 join_request 来源验证的用户,也受到方案中击杀方法的限制。例如设置击杀方法为「封禁」,当用户未通过验证时,不仅会拒绝他的加入请求,还会封禁他,即使他不在群中。被封禁后,他将无法发送加群申请。类似的「封禁再延时解封」也会以同样的原理生效,用户会被短暂禁止再次发送申请,直到临时封禁的效果结束。

基于 Approve new members 的验证刚上线,它可能存在一些 bug。将群组设置中的 Approve new members 启用,即可直接体验和帮助测试,感激不尽。

上面的投票仍然有用,请告诉我们你们对 Approve new members 的看法。


Policr Mini 即将支持基于 Approve new members 的验证,能在启用/不启用此选项的两种场景下同时工作。 你对 TG 原生功能 Approve new members(批准新成员)有什么看法?
Опрос
  •   很好,我会启用
  •   有一些缺陷,暂时不用
  •   无所谓,没有明显优势
  •   不太了解此功能
230 голосов


最近的更新

这次更新主要以优化为主,没有带来功能上的明显变化。新的变化将包含在下一次更新中,且很快会来。

1. 新增「添加到群聊」按钮,更快捷的邀请机器人进群。配合 BotFather 的 Group Admin Rights 设置,可以直接将「邀请-赋予权限」两个动作合并为一个。
2. 移除了「日志查询」这个系统菜单/页面。此页面最初用于运营者线上排查问题,现在已被彻底移除了。这主要是因为自行实现的日志存储/查询后端只能做最基本的用途,远不如专业的日志聚合分析软件,如 Grafana/Loki 和 Graylog 等。当集成后者时,前者已无意义了。
3. 修复了「删除退群服务消息」功能失效的问题,由于 TG 上游变化此 bug 可能存在了一段时间。当然你要在「验证方案」页面启用此服务消息删除才会执行,当前默认是不会删除退群服务消息的。
4. 将「工作状态检查」任务由原来的每 55 分钟改为每 4 个小时调度一次。此任务最初设计用于修复一些已失效/退出但没有即时发现的群,保留至今。
5. 对 /sync 命令和其余位置的权限检查更进一步细化。现在无论是手动同步还是主动发现自身权限变更,都会检查一些必要的权限是否启用,在缺失权限时包含相关原因。
6. 修复自定义页面添加问题时,标题不能插入空格的 bug。
7. 逐步弃用早期使用的国际化字符串技术。从 dev/commands_i18n 分支可以看到一些 .pot 文件,这是使用了更传统的 gettext 为国际化支持做准备。
8. 将图片验证资源的上传文件体积限制由原来的 7.62MB 提高到 256MB。现在可以上传非常大的验证图集压缩包了。由于后台页面不够完善,不会显示上传进度,太大的文件可能需要等待一段时间(可通过 F12 看控制台有无错误判断是否失败)。

此次更新还包含数个重大的数据层面的优化,使本项目能在服务于上万个群组时仍能较为轻松的驾驭千万级的数据量。就目前而言,此前发生过几次的长期运行不稳现象,现阶段和未来一段时间内都不会再出现了。同时此次更新移除了一些预设计的功能代码,如设置验证消息为统一入口或独立入口。被移除表示也不再位于实现计划中,永远不会实现。

通过 docker compose pull server 更新,执行 docker compose up -d 部署。注意,现在可用的镜像只有 telestd/policr-mini 和 telestd/policr-mini:develop,如若不是请更新 docker-compose.yml 文件。


近期 Policr Mini 的不稳定已被修复

最近一个多月以来 Policr Mini 出现了长时间、频繁的运行不稳。这跟服务器性能以及优化不够有关,随着机器人使用量和数据量的增加这两方面需要不断的增强才能维持住稳定的状态。于 12 小时以前,已部署了几个关键的性能优化更新,删除了一些早期的过渡设计。这起到了非常显著的效果,在这 12 个小时里服务器 CPU 的平均占用线再次位于低位。如果你此前发现 Policr Mini 出现了各种异常,这都是正常的(指的状态),因为这些天日志里有无穷无尽的错误。此次更新后日志中的异常记录几乎降低到了 0,可以说处在相当平稳的阶段。

现在的 Policr Mini 响应挺快。

预告一下即将到来的一些新变化和功能:

1. 对启用了「Approve new members」群设置的验证支持。机器人将同时支持启用/未启用此设置的双场景下的验证。简单的说用户从启用了审核新成员的链接进来,Policr Mini 会主动私聊 TA 进行验证,基于验证结果自动批准/拒绝请求。从未启用的链接进来,就是普通的验证过程。即使这些链接来自同一个群。

2. 图片验证的增强。当前的图片验证模式,在没有部署新图集的情况下图片在 TG 中的文件 ID 总是相同的,这存在被批量收集的可能。为了避免这一点,Policr Mini 将启动一个独立的服务,用于对已发送过的图片进行“重写”。经过重写的图片它的文件 ID 变化了,但是图片呈现几乎不变。具体重写的手段可能是随机替换图片中的一个像素或者对元数据进行随机性修改。这样图片每用过一次,就会变一次。永远不存在被收集文件 ID 的可能。
(目前图片验证已部署了 500 张新图片,彻底替换了旧图)

3. 新的后台页面。新的后台可能是在旧后台的基础上逐步修改的,也可能是完全重新搭建的。新后台的主要目的是具有精美的 UI 的同时兼容移动设备访问(也就是手机)。此更新到来时手机就能访问完整的后台功能了。


你遇到某些新成员进群后在机器人禁言之前发送 Hi~ 的情况吗?
Опрос
  •   遇到过,有点常见
  •   遇到过,不太常见
  •   没遇到过
1009 голосов


POLICR MINI 更新说明

此次更新北京时间凌晨 3 点已上线官方实例

1. 修复了权限检查任务中的一些错误
2. 修复了后台「登出」无实际效果的 BUG
3. 修复了后台菜单的一些样式 BUG
4. 修复了一个和今日数据统计相关的错误
5. 修复了「退出检查」任务不定期执行的 BUG(现在登录后台会发现一些无效的群已经消失了)
6. 当没有任何群组权限时后台将给予消息提示而不是白屏(白屏自身就是 BUG)
7. 新增了可选配置,以及可选参数 --independent。添加此可选参数会让实例完全独立,首页不再向官方实例请求共享的数据。此可选参数可以避免暴露一些隐私(例如实例的 URL)。感谢群友的相关反馈。
8. 支持自定义「封禁并延时解封」时长,在后台「验证方案」页面中可以设置,后台「全局属性」页面亦可修改其默认值。最小值限制为 45 秒,最大值限制为 18000 秒(5 个小时),默认值 300 秒(根据投票结果而决定)。请尽量以整分钟的秒数来设置,因为 TG 在 Recent actions 中会把时长自动换算成分钟显示,当小于一分钟时直接不显示(此处说明仅适用于将 POLICR_MINI_UNBAN_METHOD 配置为 until_date 的实例)。
9. 提高自定义问答的数量上限到 55 个(单个群)

升级方法:

1. 向 .env 中添加 POLICR_MINI_OPTS=""
2. 向 docker-compose.yml 中添加 POLICR_MINI_OPTS: ${POLICR_MINI_OPTS} ,位置是 services -> server -> environment。

完成上述修改后执行 docker-compose pull server 和 docker-compose up -d 即可。

部署教程的配置并启动部分更新了配置模板并添加了有关可选配置的内容,它对 --independent 可选参数也进行了较为详细的说明,请有需要的用户自行参阅。


如果击杀方法「踢出再延时解封」的时长可以自定义,你会设置多久?
Опрос
  •   1 分钟或者更短
  •   5 分钟到 1 个小时
  •   1 个小时到 3 小时
  •   3 小时以上
307 голосов


开发分支的所有更新已合并到主分支,并上线到官方实例。此次更新需要修改并追加新的设置,在上述文章的更新教程中有介绍。更新需要满足三处修改:

1. 将 docker-compose.yml 的 server 镜像修改为 telestd/policr-mini
2. 向 .env 中添加 POLICR_MINI_UNBAN_METHOD=until_date
3. 向 docker-compose.yml 中添加 POLICR_MINI_UNBAN_METHOD: ${POLICR_MINI_UNBAN_METHOD} ,位置是 services -> server -> environment。

完成上述修改后执行 docker-compose pull server 和 docker-compose up -d 即可。

注意:因为更新已经合并到主分支,镜像 telestd/policr-mini 可以不添加 develop 标签。如果您想跟随开发分支,获得更快的更新,也可加上 develop 标签。

顺带一提,这些更新中修复了一个安全问题。后续会做详细介绍。以及,因为时间安排有变,关于新的验证方式的实现暂时搁置。


大量更新来袭,快来试试看

!长文警告! 了解 POLICR MINI 的开发分支以及新的更新 !长文警告!

上述文章介绍了新的更新内容、升级方法,和新功能的构想。注意:上述所有更新内容在当前的官方实例 @policr_mini_bot 中都不存在,但它很快将会到来。


大约从五点开始 Telegram 出现了故障,包括机器人都不能正常工作。经检查发现此期间 Policr Mini 产生了大量的错误日志,这意味着造成了一些验证故障。可以进入 Manage Group - Recent actions 自行检查是否存在异常,避免给此期间正常加入的群成员带来困扰(如果存在能正常使用的用户的话)。

Показано 20 последних публикаций.