Forem: NaDerevo

Why I Built My Own Site and Stopped Publishing Only on Other Platforms. The POSSE Principle

NaDerevo — Thu, 02 Apr 2026 12:39:50 +0000

At some point I started thinking: where does my content actually live? A post in Telegram lives on Telegram’s servers. An article on Habr lives on Habr’s servers. A thread on X lives with Elon. If tomorrow any of these platforms decides to change the rules, ban my account, or simply shuts down — I’ll be left with nothing.

That’s when I came across a principle that the IndieWeb community has been promoting for many years. It’s called POSSE. It sounds simple, but it completely changes how you think about publishing content.

What is POSSE

POSSE stands for Publish (on your) Own Site, Syndicate Elsewhere.

In plain terms: publish on your own site first, then spread it to other platforms.

The idea is straightforward:

You write a post and publish it on your own website — this becomes the canonical version.
Then you distribute copies or links to third-party platforms — Habr, Telegram, X, Medium, whatever.
Every copy links back to the original on your domain.

That’s it. That’s the whole principle.

Why you need it

Ownership of your content

When you publish on someone else’s platform, the canonical URL belongs to them. Your content lives on their domain, under their rules and their Terms of Service. POSSE flips this around: the canonical URL lives on your domain. You own the entire publishing chain from start to finish.

Independence from third parties

A platform can go down, ban your account, or change its algorithms. If your content only exists there, you’re completely dependent on them. With your own site, you can always publish, even if everything else is unavailable.

Better search visibility

Finding your public content through any search engine is much easier and more reliable when it lives on your own domain. Anyone who has tried to find their old tweet via X search knows how painful that can be.

Links to the original strengthen it

When copies on other platforms link back to your original, several good things happen:

Discovery. People on any platform can click through to the original and interact with it directly.
Protection against copying. If someone mindlessly copies your post, the link to the original travels with it. This works like “internet aikido” — other people’s copying actually promotes your original.
SEO. Search engines see that multiple copies point to one source and rank the original higher.

Friends are more important than architecture

Your readers are scattered across different places. Some are in Telegram, some on Habr, some use RSS. POSSE doesn’t force them to go anywhere — they can keep reading where they’re comfortable. But the canonical version is always on your site.

The IndieWeb community puts it this way: “Friends are more important than federation.” You don’t have to wait for everyone to move to the perfect platform. Publish on your site and syndicate where your audience already is.

How POSSE is different from “just having a blog”

POSSE is not just “start a blog.” Creating a blog and waiting for people to come doesn’t work. POSSE is active syndication: you publish on your site first, then deliberately bring the content to where the people are.

And it’s not “install WordPress and you’re done.” The approach isn’t tied to any specific technology. You can use a static site built with Astro, Hugo, Next.js — anything. The important things are your own domain and canonical URLs.

The opposite approach: PESOS

The opposite is called PESOS — Publish Elsewhere, Syndicate (to your) Own Site. This is when you publish first on a third-party platform and only then copy it to your own site.

The problem with PESOS: if the platform is down, you can’t publish. Your content first appears under someone else’s Terms of Service, and only later (maybe) ends up with you. The ownership chain is broken.

POSSE solves this: the original is always with you, and the copies are wherever they need to be.

How it looks in practice

Let’s say I’m writing an article. My POSSE workflow looks like this:

I write and publish the article on my own website — it gets a canonical URL on my domain.
I publish a version on Habr — with a link to the original.
I make a post in my Telegram channel — with a link.
I publish a thread or link on X — with a link.
If there’s engagement on the platforms, I can pull reactions back to my site (this is called backfeed).

There’s one canonical version. There can be as many copies as you want. All of them point to the original.

My experience

I created my own website specifically with this idea in mind. I wanted everything I write to have a permanent home — a place that doesn’t depend on decisions made by any platform. Articles, notes, projects — everything lives on my domain. Habr, Telegram, and other platforms become distribution channels that link back to the original.

This doesn’t mean the platforms aren’t important. Habr is the community and discussions. Telegram is direct contact with readers. But if something changes tomorrow, my content isn’t going anywhere.

This material is based on the IndieWeb documentation: IndieWeb POSSE.

Support

If you want to support the author — subscribe to my Telegram channel.

Original

npm, March 31: RAT in Axios and Half a Million Lines of Claude Code on GitHub

NaDerevo — Thu, 02 Apr 2026 07:35:47 +0000

I wake up in the morning, open my feed — and right away, two incidents. Both about npm. Both serious. And both happened on the same day.

The first one — in Axios (yes, the one that's everywhere) — spread a RAT trojan for three hours. The second — Anthropic accidentally published the full source code of Claude Code in a public npm package. Half a million lines with prompts and architecture.

Good morning, indeed :)

Axios: 3 hours was more than enough

What happened

Someone hijacked the npm account of Jason Saayman (jasonsaayman) — the main maintainer of Axios. They changed the linked email and manually published two versions:

"axios@1.14.1" — to the latest branch
"axios@0.30.4" — to the legacy branch

The versions were live in the public registry from about 00:21 to 03:15 UTC on March 31. Three hours. For a package with over 100 million weekly downloads, that's more than enough.

How the attack worked

The nastiest part: the Axios code itself wasn't touched. Not a single line. Open the sources — everything looks clean. The trick was in package.json.

They added a dependency: plain-crypto-js@4.2.1. The package was created the day before, on March 30. The name looks innocent — just some crypto utility, who would look twice? It's never imported anywhere in the Axios code. Not once.

So why was it there?

npm install pulls in all dependencies from package.json
plain-crypto-js contains a postinstall script
The script downloads the second-stage payload from a C2 server
It deploys a cross-platform RAT trojan (for macOS, Windows, Linux)
After installation, the script cleans up after itself — it replaces package.json with a clean version

That last point is especially nasty. The trojan is already running, but when you check package.json, everything looks normal. No trace of plain-crypto-js.

Phantom dependency

This is called a phantom dependency — a ghost dependency. It's not used in the code, not imported, and exists only for the side effect during installation. Normal code review won't catch it because the .js files are clean.

You scan the sources for suspicious code? Good. But do you check package.json for new dependencies? Or postinstall scripts in transitive dependencies?

What to do right now

Safe versions:

Branch	Malicious	Safe
latest	1.14.1	1.14.0
legacy	0.30.4	0.30.3

If your project installed exactly those versions in the window from 00:21 to 03:15 UTC on March 31 — treat the system as compromised. Not "possibly". Compromised.

You need to:

Check package-lock.json / yarn.lock for "axios@1.14.1" or "axios@0.30.4"
Search for "plain-crypto-js" in the dependency tree
If you find it — the machine where npm install ran is infected
Rotate all keys, secrets, and tokens — the full set

StepSecurity, Socket, Endor Labs, Aikido, and Huntress have confirmed the details and published IOCs.

Who was behind the attack

Several sources — including Google and Reuters — point to the North Korean group UNC1069 / Lazarus. Supply-chain attacks via maintainer account takeover are their classic playbook.

Important note: the npm registry itself wasn't hacked. The infrastructure wasn't affected. The attackers simply logged in under a real account and ran npm publish. From the system's point of view, it was completely legitimate.

Claude Code: when someone forgot about .npmignore

What happened

On the same day, Anthropic released a new version of their CLI agent to npm — "@anthropic-ai/claude-code@2.1.88". A routine release. But the package included a cli.js.map file weighing 59.8 MB.

That's a sourcemap. And through it, you can restore the entire original source code of the project.

The scale

From that one file they recovered:

~512,000 lines of TypeScript
~1,900 files
The agent's internal logic
System prompts
Memory and planning mechanisms, tool handling
Unannounced features

The sourcemap also pointed to a ZIP archive in Anthropic's public R2 bucket. Security researcher Chaofan Shou was the first to post about it on X. The code was mirrored on GitHub almost instantly.

The cause

Anthropic confirmed it: a mistake in the build process. They forgot to exclude the source maps via .npmignore. That's it.

No hack. No user data leak. Just a missing line in the build config.

The version was quickly removed and a fix was released. But the code had already spread.

A Korean developer at 4 AM and 50,000 stars in two hours

While Anthropic was sending DMCA takedowns to mirrors of the leaked code, one person in Korea took a different route.

Sigrid Jin (Sigrid Jin, GitHub: instructkr) — a well-known power user of Claude Code. How well-known? According to the Wall Street Journal, in the past year he generated more than 25 billion tokens through the tool. Twenty-five billion. The guy clearly knew the architecture inside out.

On the morning of April 1, around 4 AM local time, Jin woke up to notifications about the leak. He saw Anthropic taking down mirrors of the original code and made a decision: don't copy — rewrite.

Clean room

Jin didn't fork the leaked TypeScript. That would have been taken down by DMCA in a day. Instead, he did a clean-room reimplementation — rewriting the key patterns and architecture from scratch, this time in Python:

Agent harness
Tools
Memory and planning
Swarms of sub-agents

To speed things up, he used the AI tool oh-my-codex (OmX). The repository claw-code was live before sunrise.

Different language, different code, no copy-paste — legally, this is a new creative work. Gergely Orosz from Pragmatic Engineer and other lawyers/developers confirmed: such a "clean rewrite" is legally solid.

Anthropic couldn't take the repo down via DMCA. It's still alive.

GitHub record

Then the madness began.

Time after publication	Stars
~2 hours	50,000
~24 hours	100,000+
Forks in the first day	50,000 - 58,000

50,000 stars in two hours. According to the author and several media outlets — the fastest-growing repository in GitHub history.

Later, Jin started porting the same architecture to Rust — that version also quickly gained tens of thousands of stars.

In essence, the community turned a corporate leak into a fully open clone of an AI agent in just a few hours. Jin himself later described the project's goal simply: "Better Harness Tools" — better tools that actually get things done.

You can argue whether it's ethical to build on someone else's leak. But legally — it's clean. And 100,000 stars in a day show that demand for an open alternative was huge long before March 31.

POSSE:

Na Derevo

How to Promote a Website in 2026: SEO and GEO

NaDerevo — Wed, 01 Apr 2026 14:20:00 +0000

I launched a website. Not a template on Tilda, not a one-pager on Notion — a full-fledged static site built with Astro, featuring a blog, a product landing page, and support for two languages. Before writing a single blog post, I spent a disproportionately large amount of time making sure this site would be properly visible to search engines — and, more importantly, to large language models.

This article is about what I set up, why I did it, and why in 2026 SEO alone is no longer enough.

Why Have Your Own Website?

I have a project called “Na Derevo” (On the Tree). I create digital tools and write about development. My main product right now is the Telegram bot MENO for task management. Before this, everything lived on third-party platforms: articles on Habr, posts on dev.to, updates in my Telegram channel.

The problem: the content was scattered, nothing was connected, and if tomorrow any platform changed its rules — I would lose everything.

That’s why I built a website that solves three main tasks:

MENO landing page — a place to send people who want to understand what this bot is.
Blog — so my articles live with me, not only on someone else’s platforms.
Central hub — so everything I do is in one place.

And there’s one more, less obvious reason.

POSSE: Publish on Your Own Site, Syndicate Elsewhere

There’s an approach called POSSE — Publish on Own Site, Syndicate Elsewhere. The idea is simple: the original version of the content always lives on your own website, while you publish copies on Habr, dev.to, Reddit, or anywhere else.

Why do this:

You retain the rights. You are the author, you have the canonical URL, you control the text.
You don’t depend on platforms. A platform can shut down, ban you, or change its algorithms — your content remains safely on your own domain.
You can connect any tools. RSS, newsletters, auto-posting — anything you want, without platform restrictions.

This article, by the way, was also written following the POSSE principle — the original lives in my blog, and what you’re reading now is the syndicated version.

Technical Foundation: Astro and Two Languages

The site is built with Astro — a framework for static websites. No client-side JavaScript for content; everything is rendered into clean HTML during the build process. For search engines and AI crawlers, this is ideal: they see a ready-made page, not an empty <div id="app"> that still needs to be executed.

The site is bilingual:

/ru/ — Russian version
/en/ — English version

Blog posts are stored in Markdown using Astro Content Collections — one file per language. This allows me to maintain one blog in two languages, while each article knows about its alternative language version.

The root of the site (/) is not a content page. It’s a redirect entry: a script detects the browser language or the user’s saved preference and redirects to /ru/ or /en/. This is convenient for UX. For SEO — it’s a compromise, which I’ll mention below.

SEO: What I Set Up and Why

SEO in 2026 is no longer about “stuffing keywords into the text.” It’s a set of technical signals that help search engines understand what the page is about, what language it’s in, and which version to show the user.

Here’s what I configured.

Basic Meta Tags

Every page has its own:

<title> — the title visible in search results
<meta name="description"> — the description shown under the title in search results

It sounds obvious, but the number of sites where every page has the same title is surprising. My titles and descriptions are unique for each page: homepage, MENO landing page, and every blog article.

Canonical

<link rel="canonical" href="https://naderevo.com/ru/blog/my-article/" />

The canonical tag tells search engines: “this is the original version of this page.” If content is available under multiple URLs (for example, with and without parameters), canonical indicates which URL should be indexed. Without it, search engines may treat duplicates as different pages and split the ranking.

Hreflang

<link rel="alternate" hreflang="ru" href="https://naderevo.com/ru/blog/my-article/" />
<link rel="alternate" hreflang="en" href="https://naderevo.com/en/blog/my-article/" />

Hreflang is a way to tell search engines: “this page has a version in another language, here it is.” Google uses hreflang to show users the correct language version in search results.

I have hreflang set up for all pages, including blog posts. Alternative links are built using the routeSlug field in the frontmatter — a special field that explicitly defines the URL. This is more reliable than relying on automatic slugs.

Open Graph and Twitter Cards

<meta property="og:title" content="..." />
<meta property="og:description" content="..." />
<meta property="og:image" content="..." />
<meta name="twitter:card" content="summary_large_image" />

These are what people see when someone shares a link on social media or messengers — title, description, and image. Without OG tags, the link looks like a bare URL. With them — it appears as a nice card.

For now, I’m using universal OG images: one for the site, one for the blog, and one for MENO. Not ideal for CTR, but sufficient at the current stage.

Robots.txt and Sitemap

User-agent: *
Allow: /
Sitemap: https://naderevo.com/sitemap-index.xml

The robots.txt is open to everyone — both search engine bots and AI crawlers. No blocks.

The sitemap is generated automatically during the build and includes all indexable pages. I removed junk URLs and the root / (because it’s a redirect, not content).

Structured Data (JSON-LD)

This is markup that helps search engines not just read the page, but understand what’s on it. Not “text about a bot,” but “this is a software product, here’s its name, here’s the author, here’s the rating.”

The site has three types of structured data:

WebSite on the homepage — description of the site as an entity
SoftwareApplication on the MENO landing page — description of the product
BlogPosting on articles — description of each article with author, date, and headline

Example for an article:

{
  "@type": "BlogPosting",
  "headline": "How I Stopped Losing Tasks in Telegram",
  "author": {
    "@type": "Person",
    "name": "Nikita"
  },
  "datePublished": "2026-07-10",
  "description": "..."
}

Search engines see this and can use it for rich snippets — enhanced cards in search results.

GEO: What It Is and Why It Matters

Now for something many people still don’t take into account.

GEO — Generative Engine Optimization — is the optimization of a website not for search engine robots, but for large language models. ChatGPT, Perplexity, Gemini, Claude — they all know how to crawl websites, read content, and cite it in their answers. The question is: will your site be among the sources they quote?

If SEO is “how to get into Google’s search results,” then GEO is “how to get into ChatGPT’s answers.”

It may sound like something from the distant future, but it’s already working. People are increasingly searching not in Google, but by asking AI. And AI takes information from somewhere. If your content is clean, well-structured, and accessible for crawling — your chances of being cited increase.

What Matters for GEO

Content in clean HTML, not client-side JavaScript. AI crawlers don’t always execute JavaScript. If your content is rendered on the client — the model may see an empty page. Astro renders everything to HTML during build — the crawler sees ready text.

Don’t block AI crawlers. Some sites block ChatGPT, Anthropic, and other bots in robots.txt. I deliberately left everything open. If a model wants to read my content and reference it — be my guest.

Structured data. JSON-LD helps not only Google but also language models. When a page has BlogPosting markup with author, date, and description — it’s easier for models to understand the context and decide whether to cite it.

Author layer. This is a less obvious but important point. Content without an author looks impersonal. The model cannot attribute it, and therefore is less likely to cite it. I added a visible author block to every article and mapped the author in the schema to a Person type with a name.

What GEO Doesn’t Cover (Yet)

The root of the site remains a redirect entry — for a language model, this is a weak page. If someone asks AI “what is naderevo.com,” the model may not get an answer from the root because there’s no content there — only a redirect script.

Comparative articles in the blog can be strengthened with links to primary sources — this increases the model’s trust in the content.

The homepage is brand-oriented but not answer-first — it doesn’t answer the question directly in the first paragraph. For GEO, it’s better when the page starts with a direct answer and then expands on the details.

None of this is critical, but it remains on the to-do list.

Google Search Console and Yandex.Webmaster

On the day I wrote this article, I registered the site in Google Search Console and Yandex.Webmaster. There’s no statistics yet — both need time to process.

Why do this even if you have a brand-new site with zero traffic:

You tell the search engine about your existence. Without registration, Google might find your site on its own — or it might not. Search Console is a guarantee.
You can submit the sitemap manually. The search engine will start crawling pages faster.
You can see indexing errors. If something is broken — hreflang, canonical, redirect — Console will show it. Better to find out now than in three months.
Query data. When traffic appears, you’ll see which queries people find your site with, which pages are shown, and with what CTR.

For Yandex, everything is similar, only through Webmaster. If you target a Russian-speaking audience — this is mandatory.

I registered in both. In a couple of weeks I’ll check what they found and share the results.

Lighthouse: Making Sure It Wasn’t in Vain

Another tool worth knowing about is Lighthouse. It’s a built-in audit in Chrome DevTools that evaluates a page on four parameters:

Performance — how fast the page loads and becomes interactive
Accessibility — how accessible the site is: contrast, alt texts, keyboard navigation
Best Practices — adherence to web standards: HTTPS, correct headers, no deprecated APIs
SEO — basic technical SEO hygiene: meta tags, canonical, readability for crawlers

Each parameter is scored from 0 to 100. The green zone is 90+. This is not a guarantee of success in search results. I ran the audit on my site. Results:

Homepage:

Performance	Accessibility	Best Practices	SEO
99	100	96	100

MENO Landing Page:

Performance	Accessibility	Best Practices	SEO
93	95	96	100

The homepage scores almost maximum across all parameters. This is thanks to Astro: static HTML without client-side JavaScript loads instantly.

The landing page is slightly lower in Performance (93) and Accessibility (95) — it has more content, product screenshots, and interactive sections. That’s normal. 93 is still in the green zone, and I know where to dig if I want to push it further.

Why run Lighthouse at all: it’s a free “idiot check.” A couple of minutes — and you see if you forgot alt text on an image, if a font is loading in a blocking way, or if the meta description is empty. Better to hear it from Lighthouse than from a user who left the site after half a second.

Summary

The site was launched yesterday. Traffic is still zero. But the technical foundation so that both search engines and AI models can see the content is ready.

What has been done:

Static site on Astro, two languages, clean HTML
SEO: canonical, hreflang, OG, structured data, sitemap, unique meta tags
GEO: open robots.txt, author layer, Person schema, content without client-side JS
POSSE: original content on my own site, syndication to other platforms
Google Search Console and Yandex.Webmaster connected

SEO and GEO are marathons. GEO rules are still evolving. But if you don’t start now — catching up later will be much harder.

Links

Website: naderevo.com
MENO Bot: @menoapp_bot

4 Telegram Bots for Task Management Right in the Messenger: Comparison in 2026

NaDerevo — Mon, 23 Mar 2026 10:00:00 +0000

Tasks in Telegram arise faster than you can write them down. "Buy milk after work," "call with the client on Monday at 3 PM," a one-minute voice message with three instructions inside — all this flies by in the feed and sinks after twenty messages. Bookmarks help save a link, but won't extract the date from the text or remind you on time. Chat search will find a word, but won't group tasks by deadlines or priorities.

The standard approach is to transfer the task to a separate planner: Todoist, Notion, Trello. But each such transfer is a context switch. Open the app, create a card, fill in fields, return to the chat. On one task, it's thirty seconds; on twenty a day — a separate routine that most people abandon after a few days.

An alternative is to solve the problem inside the messenger itself. I reviewed four Telegram bots for tasks that are actively maintained in 2025 and regularly mentioned in reviews: @SkeddyBot, @RemindMegaBot, @SmartScheduler_bot, and @menoapp_bot. Each extracts tasks from text, but does so differently and for different scenarios.

Disclaimer: @menoapp_bot is my own project. I won't pretend to be conducting an impartial study. But I'll try to break down each bot honestly — with pros and cons, including my own.

How the Comparison is Structured

The analysis is based on the bots' official descriptions, documentation, and public reviews. I didn't conduct blind testing with accuracy measurements on a thousand examples — that would require a separate methodology and article. Instead, I focused on the stated capabilities and architectural differences that determine which scenarios each bot suits best.

Key questions I sought answers to:

How does the bot receive a task — via commands, natural language, voice?
Is there an interface for viewing and managing tasks?
How are recurring reminders handled?
What's free, and what's paid?

Summary Table of Telegram Task Bot Features

Feature	@SkeddyBot	@RemindMegaBot	@SmartScheduler_bot	@menoapp_bot
Text Parsing	Natural language	Natural language	Natural language	AI extraction from arbitrary messages
Voice Messages	No	No	Yes	Yes
Reminder Type	Push in Telegram	Push + snooze + defer	Push	Auto-detect time + push
Viewing Interface	Web app skeddy.me	Inline chat buttons	Inline chat buttons	Telegram Mini App
Recurring Tasks	Via web interface	Built-in	Basic	From message context
Languages	Russian	Russian, English	Russian	Russian, English
Price	Freemium	Free	Free	Freemium

The table shows stated capabilities. The quality of each implementation is a separate question, which I'll partially address below.

@menoapp_bot — AI Task Planner in Telegram with Voice Input

This is my project, so I know it inside out — and its weaknesses as well as its strengths.

The key difference from the previous three bots is the approach to receiving a task. SkeddyBot, RemindMegaBot, and SmartScheduler_bot expect you to write a specific phrase to the bot: "remind me X at Y." Menoapp_bot tries to extract tasks from regular messages. You write "demo tomorrow at 6 PM, don't forget to prepare slides" — the bot parses the text, identifies the task, determines the date, and sets a reminder if needed. The same works with voice messages: the bot transcribes the audio and applies the same AI parsing to the transcript.

The second difference is the Telegram Mini App for viewing and editing tasks. Instead of scrolling through the chat for past reminders, you can open the mini-app and see all tasks with dates and statuses. This solves a common problem for all chat bots: in conversation format, it's hard to overview a list of twenty tasks.

The bot supports Russian and English.

What's missing, and what doesn't work perfectly. AI parsing isn't deterministic. The phrase "after lunch" might turn into 2 PM or 3 PM depending on context, though I'm working on deterministic post-processing for such cases. Complex constructions like "sometime next week, closer to Thursday, maybe" stump any model. No snooze mechanic like RemindMegaBot. Recurring tasks are supported, but the implementation is basic so far.

Additionally, the project has a small audience yet — about 120 users. This means it's tested on a limited number of real scenarios, and edge cases will surely surface.

Best for: those who want to create tasks via voice or free-form text and need a visual interface for viewing. Especially for Russian speakers — as of writing, it's the only bot of the four with full Russian support.

Link: @menoapp_bot

@SkeddyBot — Time-Tested Reminder Bot in Telegram

SkeddyBot has been running since 2016 and has built a stable audience — about 13 thousand active monthly users per open data. It's one of the oldest Telegram reminder bots, and its main advantage is predictability.

The principle is simple: you write a phrase in natural language to the bot, it recognizes the date and time, creates a reminder. "Check email tomorrow at 10am" — and tomorrow at ten you'll get a notification. For one-off reminders, it works flawlessly.

Recurring tasks are set via a separate web interface at skeddy.me. This is both a pro and a con: on one hand, the web gives more flexibility for complex schedules; on the other, it breaks the "everything inside Telegram" idea. If you wanted to avoid app switching, opening a browser for recurring reminders might disappoint.

What's missing. No voice messages. Doesn't extract tasks from conversation context: you need to consciously write a specific phrase with time to the bot. So it's a tool for people who already formulated the task in their head and want a reliable reminder. No more, no less.

Best for: those needing a reliable, simple reminder in Telegram without extras. Proven over years, doesn't break, does one thing well.

Link: @SkeddyBot

@RemindMegaBot — Flexible Reminders with Deadline Deferral

RemindMegaBot solves the same base task as SkeddyBot — reminders from text messages — but adds handy mechanics for task management that make daily use more comfortable.

The main one is snooze and deferral. When a reminder arrives, you see buttons: mark as done, defer to another time, or postpone. It's a small thing, but in practice, it changes a lot. Reminder "call the doctor" comes, but you're in a meeting — tap "in an hour" instead of re-remembering. SkeddyBot lacks this: reminder came, and it's gone.

Recurring tasks are set right in the chat, no browser needed. "Workout every Wednesday at 6 PM" — bot creates a series. After /start, it asks for timezone, avoiding time shift issues.

What's missing. Like SkeddyBot, no voice messages. No task lists or interface to view all scheduled items — just a stream of reminders in chat. If you accumulate twenty reminders a week, you can't overview them.

Best for: those prioritizing reminder flexibility — defer, snooze, repeats. Great for routine tasks that often shift.

Link: @RemindMegaBot

@SmartScheduler_bot — Bot for Voice Reminders in Telegram

SmartScheduler_bot stands out with one key feature absent in SkeddyBot and RemindMegaBot: voice message recognition. You dictate "meeting tomorrow at 2 PM" — bot transcribes, finds the date, creates a reminder.

For people who dictate more than type — and there are many Telegram users like that — this is a big plus. No need to stop, switch to keyboard, formulate text. Said — done.

Text input works on natural language too, like the previous two. Bot is free, no complex setup — /start and go.

What's missing. No snooze or deferral. No web or mini-app for task viewing — all management via bot chat. Recurring tasks basic.

Essentially, SmartScheduler_bot is the same "simple reminder" approach, but with voice added. If voice input is critical and other features secondary — solid choice.

Best for: those used to dictating messages and wanting voice reminders without extra steps.

Link: @SmartScheduler_bot

Which Telegram Task Bot to Choose for Your Scenario

All four bots solve one problem — tasks get lost in chats — but at different levels.

For a simple reliable reminder — SkeddyBot. Time-tested, predictable, no surprises. Ideal for those who know exactly what and when to remind.

For reminder flexibility — RemindMegaBot. Snooze, defer, repeats out of the box. For tasks that often shift: call back later, reschedule workout, postpone till tomorrow.

If you dictate more than type — @menoapp_bot or SmartScheduler_bot. Both handle voice. SmartScheduler simpler and more predictable; menoapp_bot additionally extracts structure from voice: task, date, priority.

If tasks arise in conversation context — @menoapp_bot. For cases where a task isn't a separate "write command to bot" action, but a regular message from which to auto-extract essence, date, priority.

*If you've used any of these bots or know others worth mentioning, happy to discuss in comments.

I kept losing tasks in Telegram chats. So I built a bot.

NaDerevo — Fri, 20 Mar 2026 14:00:00 +0000

TL;DR: All my work-related communication happens on Telegram, but traditional task planners require manual data transfer and a separate routine. I spent a long time looking for a way to organize the chaos right within the messenger, couldn’t find anything suitable—so I ended up building my own bot. Here’s how I went from problem to solution.

Context: Why Telegram Is Both My Office and My Notebook

I spend almost the entire day on Telegram. It’s where client requests pour in, team updates come through, sudden ideas strike at 3 a.m., and I jot down quick “don’t forget” notes. The messenger has long been the main hub for all my work.
But there’s a problem: information in chats is a stream, not a system. In the evening, I open a chat—hundreds of messages—and frantically search for that one single phrase about a deadline. Once, I missed a meeting because I missed a forwarded message—the client called, furious, and I blushed and made excuses.
That’s when I first started wondering: how do people actually solve this

What I Tried and Why I Stopped

First, I took the standard approach—third-party task managers.

Tool	What I tried	Where it fell short
Todoist	Manually transferred tasks from chats	Stopped after 3 days—too much switching back and forth
Notion	Created a task database, sent myself links	Quick tasks got lost in the clunky interface
Trello	Created cards based on chat threads	The board turned into a graveyard—I opened it once a week
Google Keep	Copied messages into notes	Unstructured notes—same chaos, just in a different place

The pattern is always the same: c*opy text → switch to the app → create a task → set a date → return to the chat*. Each task takes 30–60 seconds of manual work. With dozens of tasks a day, this turns into a separate chore that no one wants to do.
I realized that the problem isn’t with any specific app, but with the approach itself: any external task planner creates friction because it requires you to leave the context in which the task originated.

The idea: if the mountain won’t come to Muhammad

At some point, I flipped the question around. Instead of asking, “Where should I move tasks from Telegram?” I asked myself, “Why move them anywhere at all?”

The logic is simple:

All tasks, agreements, and deadlines already come into Telegram as messages.
I spend my entire workday here anyway.
So task management should live right here—without switching contexts.

I started looking for Telegram bots that could turn messages into tasks. I found a few, but something was always off: one required strict command syntax, another couldn’t parse dates from natural text, and a third looked like a prototype abandoned two years ago.

In the end, I decided to write my own.

The result: the MENO bot

The concept is as simple as it gets—you type or speak to the bot just as you would in a chat, and it automatically extracts the task.

No special syntax, no slash commands for basic scenarios—just natural language.

Key features:

Create tasks from regular messages—type or speak, and the bot will parse the content and date
Reminders—the bot determines the time from the context and sends a notification via Telegram
Lists and priorities—a minimalist structure without complex boards or nested projects
Everything within the messenger—no switching between apps

Essentially, this is an attempt to create a task manager that doesn’t feel like a task manager. You simply type in the chat—and order emerges on its own.

What problem does this actually solve?

Messengers are fast and chaotic. Planners are structured, but they require discipline. All the work happens in the former, but it needs to be stored in the latter. And this disconnect between “where tasks are created” and “where they should live” is the main source of waste.

Traditional tools try to drag you into their ecosystem: open the app, create a card, fill in the fields. My idea was the opposite—to bring structure to where you already are. You don’t go to the planner; the planner comes to your chat.

That said, I’m not trying to replace Notion or Jira for complex project management. This is a solution for those whose tasks are born in conversations and quietly die there, never making it to any task manager.

What's Next

The bot is live and I use it daily for my own workflow.

If you spend most of your workday in Telegram, I'd genuinely
like to know: how do you handle tasks that come from chats?
Do you have a system?

Bot: @menoapp_bot