奖品详情： 奖品内容 ：Telegram 账号 x 1 账号属性 ：毛里塔尼亚 (+222) 区号，已养号 3-6 个月，稳定性佳。 交付方式 ：中奖后通过论坛私信发送登录链接/直登信息。 活动时间： 开始时间 ：发帖时间 截止时间 ：2026年[4][18] [18：00] 参与方式： 在本帖下回复任意内容即可参与。 抽奖规则： 每位用户仅允许参与一次 （已开启慢速模式限制）。 抽奖工具 ：使用官方插件 lottery.linux.do 进行随机抽取。 开奖流程 ：活动截止后，我会手动关闭话题，并调用 @lottery_bot 发布中奖结果。 注意事项： 本活动严格遵守论坛《关于发起论坛抽奖的注意事项》。 严禁任何加群、关注、点赞等附加操作要求。 中奖者请在结果公布后 24 小时内私信联系我领奖，逾期视为放弃。 所有规则及抽奖结果由活动发起人和论坛 管理团队 最终解释。 期待您的积极参与，祝您好运！ 127 个帖子 - 124 位参与者 阅读完整话题
如题。虽然好像没什么用 4 个帖子 - 4 位参与者 阅读完整话题
第一次遇到，直接所有设备被提出，短信验证码收不到，然后小号上去看还是在的，有佬友遇到并解决的方法吗，TelegramX试过也接不到 6 个帖子 - 5 位参与者 阅读完整话题
Telegram 客户端已官方支持中文了 提供 简体中文 和 繁体中文 选项 更改语言方法： Settings → Language → Chinese 设置 → 语言 → 中文 1 个帖子 - 1 位参与者 阅读完整话题
刚刚登入TG，弹出来一个框，让我选择语言 英语 中文 其他（好像是） 不需要BOT切中文了 7 个帖子 - 3 位参与者 阅读完整话题
今天打开TG的时候弹出一个语言选择的选项，居然让我在中文和英文选择 这是终于官方支持官方中文了吗 20 个帖子 - 19 位参与者 阅读完整话题
要么就是收不到验证码，要么就是进去了要订阅会员才让进，有没有佬友知道如何解决呢？ 4 个帖子 - 4 位参与者 阅读完整话题
想问下各位佬友，目前搜索 Telegram 上的资源有哪些方案？是通过资源搜索站，还是 Grok 这类 AI 搜索工具比较好？ 3 个帖子 - 3 位参与者 阅读完整话题
telegram 输入“/”之后为什么机器人不弹命令了呢?以前都可以的，突然发现不行了 1 个帖子 - 1 位参与者 阅读完整话题
I was trying to solve a pretty simple problem: how to keep geo-notes organized and actually usable without building a multi-level UI. Instead of building another app, I started wondering if Telegram — with its search and message model — could handle more than it seems at first glance. At some point, I approached the problem from a very simple angle: What if a location could be treated as a tag? Not just a generic label, but something more concrete — essentially latitude and longitude encoded into a hashtag-like format. A representation that can always be turned back into actual coordinates. In practice, a caption might look something like this: `#geom3eaZ76OH4 ` where the links to something like `https://www.google.com/maps?q=11.453792,104.957634` So the tag acts as a compact, searchable identifier, while the link preserves the exact location in a human-friendly way. Once you have a consistent location tag, everything else falls into place quite naturally. Any Telegram-supported content — messages, media with captions, text — can be tied to that same tag. Since everything is already indexed, you automatically get a connected set of data around a place. In practice, this means a single location tag becomes a kind of anchor. You can describe a place, add notes, attach photos, or extend it over time — all linked through that one reference and fully searchable. At that point, you're not really building a separate storage system anymore. You're leaning on Telegram’s own indexing and letting it do most of the heavy lifting. If you take this idea a bit further, you can introduce an additional layer using another tag. For example, something like `#myTrip` to mark a group of geo-notes that belong together. If messages with location tags are also labeled with `#myTrip` (for example, within a topic or a dedicated thread with the same name), you can start linking different places into a route. In practice, this turns a set of individual location anchors into a connected sequence. You’re no longer just describing places — you’re organizing them into paths that can be revisited, searched, and shared. At that point, it starts to feel less like a collection of notes and more like a lightweight, flexible way to build and navigate routes directly inside Telegram. There was a trade-off, though. Since the system restructures messages to keep everything consistent and searchable, I lost the ability to edit them in a normal way. Instead of direct edits, messages are effectively rebuilt. To keep things simple and stay within Telegram’s native interaction model, I introduced a minimal set of reply-based interactions. For example: * replying with `=new text` replaces the caption * replying with `=` clears it down to the service tags * replying with `+some text` appends a new line It’s not as convenient as standard editing, but it keeps everything consistent with the overall idea: no complex UI, just structured messages and lightweight interaction. In the end, this approach comes with some clear trade-offs — but also some practical advantages. On the plus side: * there’s no separate database to maintain — everything stays inside Telegram * no multi-level menus or complex UI flows * no AI layer in between — just direct interaction with structured messages At the same time, this simplicity has its limits. Since the system doesn’t store data outside of Telegram, it can’t help recover anything you delete. If a message is gone, it’s gone — there’s no secondary storage or history to fall back on. Another limitation is that the structure only really works inside Telegram. If you try to move it elsewhere, it loses most of its connections and interactivity, because everything relies on native message behavior and search. So it’s not a system that tries to control or preserve everything. It’s closer to a lightweight layer that helps organize what’s already there, while leaving the underlying behavior unchanged. Comments URL: https://news.ycombinator.com/item?id=47789821 Points: 2 # Comments: 0
佬友们，那些低价plus会员，比如七元八元的，都是在这激活的吗，我感觉是 34 个帖子 - 27 位参与者 阅读完整话题
Virtual AI friends, personalized to you, that chat you (or don't!) on their own work/sleep schedules based on their timezones. They sometimes initiate chats. They sometimes go silent for hours. Just like real friends. I've been "dogfooding" this for the past week, and I think it's actually kind of neat. It's way better than generically chatting with an LLM. This repo includes a detailed setup wizard. You give it some info about yourself, which can include personal blogs/websites to scrape, github, mastodon, text documents, or just paragraphs you write off the top of your head. It builds a profile of you, and then builds _them_ off of that. You invite your new friends to your group chat by selecting and possibly editing them in a TUI. Then you can just deploy to local Docker and forget about it. Too crepy? Drop the docker container and remove ~/.sudomake-friends. I know this reeks of dystopian future, I get it. I think of it as a fun little toy, and I also kind of just want to see what the community feedback is. Comments URL: https://news.ycombinator.com/item?id=47787261 Points: 4 # Comments: 0
想着找一个飞机的命令行下载工具,找了tdl和telegram-files,有佬用过吗,telegram-files现在卡在扫码登录,就是报错error ,也没有详细信息,tdl 没发现文档里可以显示跟踪下载最新文件,有没有其他工具推荐呢 1 个帖子 - 1 位参与者 阅读完整话题
没有私聊过，群都能进，目前看到的唯一限制就是不能发言 1 个帖子 - 1 位参与者 阅读完整话题
加入L站几天了，喜欢这边氛围，来贡献一下 debug 帖，给用 claude code telegram 官方插件的佬们做个参考 背景/问题 题主一台机器上分了 3 个不同的目录在同时跑 Claude Code，3 个账号都分别接入了 telegram bot，最近几天使用的时候发现 0 号 bot 非常不稳定，发的消息经常进不到 session 里，尝试重启 tg session 或者清理后台 telegram mcp server 僵尸进程都没用，与此同时 1 号 bot 和 2 号 bot 却都能正常回话，遂开始了排查 排查过程与证据链 1. 进程状态确认（ps aux） 三个实例均正常启动（2:31-2:32am）： 实例 Claude PID bot PID launcher PID .claude 94315 94327 94325 .claude1 94151 94163 94161 .claude2 93990 94001 93999 关键异常 ： 发现两个孤儿高 CPU 进程 PID 命令 PPID 运行时长 CPU 状态 18230 bun server.ts 1（孤儿） 3天17小时 ~100% R 39394 bun server.ts 1（孤儿） 1天13小时 ~99% R 与正常 bot 进程状态对比：94001/94327/94163 均为 0% CPU，S+ 状态。 RSS 内存对比 .0号 bot 进程（94327）的 RSS 内存仅 26MB，而 .1号（94163）和 .2号（94001）均在 50MB 以上。内存偏低猜测 94327 早早放弃、几乎未处理任何对话；促使题主进一步检查进程环境变量和版本代码。 实例 Bot PID RSS 内存 .claude（异常） 94327 ~26 MB .claude1（正常） 94163 ~50 MB+ .claude2（正常） 94001 ~52 MB 2. 环境变量确认（ps eww） 18230: TELEGRAM_STATE_DIR=/Users/xxx/.claude2/channels/telegram CLAUDE_PLUGIN_ROOT=...telegram/0.0.4 → 使用 .claude2 的 bot token 39394: TELEGRAM_STATE_DIR=/Users/xxx/.claude/channels/telegram CLAUDE_PLUGIN_ROOT=...telegram/0.0.4 → 使用 .claude 的 bot token 此处发现本机上同时运行着两个版本的 telegram mcp server，而且两个僵尸盗版 bot 均为 0.0.4 版本 的插件 server ，pid 不在任何 bot.pid 文件中。 3. 版本代码差异（直接读取本机 cache 中的源码） 0.0.4 的 409 处理（进程 39394/18230 使用，无退出上限 ） ： for (let attempt = 1; ; attempt++) { try { await bot.start({...}) } catch (err) { if (err instanceof GrammyError && err.error_code === 409) { const delay = Math.min(1000 * attempt, 15000) await new Promise(r => setTimeout(r, delay)) continue // 遇到 409 无限重试，无任何退出条件 } } } 0.0.5 的 409 处理（当前正版 bot 94327 使用，最多 8 次） ： if (err instanceof GrammyError && err.error_code === 409) { if (attempt >= 8) { process.stderr.write(`409 Conflict persists after ${attempt} attempts — Exiting.\n`) return // 超过 8 次退出 } // ... } 就此得出一个非常好笑的结论 ： 39394（0.0.4）：永远在 continue 死循环，每次等 max 15s，永不退出 → 持续消耗 CPU，永远占着 telegram 槽位 94327（0.0.5）：8 次失败后 return 退出轮询循环 → 变成"死的" MCP server，不再尝试连接 0.0.5 修复了 0.0.4 没兜底的问题，但代价是一旦遇到真正顽固的僵尸盗版（就是 39394），正版 bot 反而率先认输，变成了死 server…… 4. 清理脚本失效分析 我之前有一个一键清除所有僵尸进程的脚本 kill_telegram_mcp.sh： pids=$(ps aux | grep -i telegram | grep -v grep | awk '{print $2}') echo "$pids" | xargs kill -9 经过验证发现 39394 和 18230 完全不会出现在 grep 输出中 ……也就是说这个脚本根本没有清理完真正抢端口的僵尸进程= =，因为实际运行的这两个僵尸子进程命令行只有 bun server.ts ，没有 telegram 关键字……只有启动时的命令（ bun run --cwd .../telegram/... ）才包含 telegram …… 所以之前每次不干净的清理反而会不停的制造新孤儿： grep -i telegram 匹配到启动进程 kill -9 launcher → 启动进程死亡 Unix 下 kill 父进程不会杀死子进程，server.ts 被 reparent 到 init（PPID=1） 0.0.4 无 orphan watchdog → 子进程永不自终 新的 0.0.4 孤儿堂堂诞生 5. 网络连接状态（lsof 直接观测） 最后通过跟代理之间的链接最终确定：两个僵尸的 unix socket 对端均为 (none) ，父进程早已死亡，mcp 连接断开。 进程 unix socket TCP（代理 7897） 结论 94001 .claude2 bot 正常连接 有 ，ESTABLISHED 正在轮询 telegram 94327 .claude bot 正常连接 无 未在轮询 18230 zombie ->( none) 断开 无 mcp 连接已死 39394 zombie ->( none) 断开 无 mcp 连接已死 未解之谜 查出来 0 号 bot 和 2 号 bot 都有 0.0.4 残留版本的僵尸进程，但是启动时 0 号 bot 被卡住了，2 号却不知为何没有被卡住，鉴于没有启动时留下的任何日志，所以这个问题不得而知了 吐槽：很歹毒的一个 bug，每次启动 tg plugin session 的时候，mcp server 就算没连上也不会给你报任何异常（右下角一闪而过那种很难看到），你退出 session 时出现异常 mcp server 没有正常关闭也不会给你报任何异常，总之就是生死都没有任何个异常，一旦你异常退出一次没注意，不清理完僵尸进程你后面都别想再正常使用了…… 1 个帖子 - 1 位参与者 阅读完整话题
Article URL: https://github.com/sartoopjj/thefeed Comments URL: https://news.ycombinator.com/item?id=47739532 Points: 2 # Comments: 1