Spaces:
Sleeping
Sleeping
Commit History
-
onboarding: sweep every known chat, so no group is ever left behind by hand
ilang-ai +1: Claude Opus 5Layers 2 and 3 only attach at the moment the bot is added, which left two holes that could only be closed manually: chats that predate the feature never get nagged at all, and the JobQueue is in memory, so a restart silently drops every pending nag. This bot is the live proof - it sits in 9 chats with no rights that nothing was ever going to act on. Layer 4 is a run_repeating sweep, 6 hours apart, first pass 5 minutes after start. Every known chat is probed; the rights-less ones enter the same 1/2/3/5/10 minute nag cycle and leave on their own. It also picks up chats whose rights were revoked later, which nothing else watched for. The sweep itself sends nothing, leaves nothing and writes no blocklist row - it only decides who enters layer 2, so every existing safety rule still applies. Two things it has to get right: - 'gone' is now its own member_state, separate from 'no rights'. left/kicked fails the same rights predicate as an unpromoted admin, so without the split the sweep …dfca837 -
onboarding: never let a network blip trigger a leave + blocklist
ilang-ai +1: Claude Opus 5Same three fixes as the private tree, plus the two wiring gaps that made them worse here. The core problem: has_rights collapsed every exception into "no rights", and at the 600s slot that answer went straight to leave + blocklist. probe_rights is now tri-state (True/False/None); only a confirmed False may act. An unreadable answer requeues the same slot 60s later, up to 3 times, then gives up without leaving. The nag's send_message no longer treats a timeout as "muted/removed" - only Forbidden and the chat-is-gone BadRequests do, and that path leaves without blocklisting. Error-derived cache negatives now live 20s instead of 300s, so a blip can no longer silence a group for five minutes. Also here: - /groups (list + unblock) was private-only, and unblock() was dead code in this repo. A wrong entry was only undoable by hand-editing bot.db on the VPS. - ADMIN_USER_ID was claimed by whoever sent the first /start after a restart. On a public bot that is a stranger, and it re-opened …76a45e0
-
入群授权催办：没权限就不判定，10 分钟仍未授权自动退群拉黑
ilang-ai动机是一个真实的额度消耗攻击面：任何人都能把 bot 拉进任意群，而没有管理权限时 bot 删不掉封不了，却仍把每条群消息送去 AI 判定，判完才发现无权处置。 线上实测一个陌生群 24 小时刷出 447 条「检测到 spam 但没权限」，全是白烧的调用。 拉进一个高流量群、不给权限，就能静静烧掉额度。 三层处置，新增 modules/onboarding.py： 1. 没权限时根本不判 —— 这才是真正掐掉成本的地方。has_rights() 要求 administrator + can_delete_messages + can_restrict_members 三者齐全， 缺一即视为无权限；查询失败也按无权限处理（宁可少判，不在未授权群烧调用）。 带 300 秒缓存，且 my_chat_member（权限变更时同样会推送）到达时立即作废， 不必等 TTL。位置放在节点采集之前，未授权的群一概不消耗任何资源。 2. 加进群后按 1/2/3/5/10 分钟催办，措辞逐级明确，第 5 分钟起预告将退群。 任一次催办时若已拿到权限，立即取消全部剩余任务。 催办发不出去（被禁言/被踢）说明留着也没意义，直接进入退群流程。 3. 10 分钟仍无权限：说明原因、退群、写入 group_blocklist。 之后再被拉进同一个群直接退且一言不发 —— 否则反复邀请就是一个免费的 「让 bot 说话 + 处理流量」循环。 私有版另加超管命令 /groups 查看黑名单、/groups unblock <chat_id> 解除。 沙箱验证两边各 21/21：权限判定五种组合（含线上那个被禁言的俄语群场景）、 排程时间点、有权限时绝不误退群、无权限时逐级催办且不提前退、 10 分钟到点退群并拉黑、拉黑后拦截与解除、缓存命中与作废。f691796