Botio is a platform-agnostic framework for building chat bots.
The goal of Botio is simple: write your bot logic once and run it on multiple messaging platforms without rewriting your handlers for each platform.
Building bots for different platforms is often repetitive.
Every platform has its own:
- Update structure
- User model
- Message format
- Webhook payload
- API methods
As a result, developers usually end up maintaining separate codebases for Telegram, Bale, Rubika, Eitaa, and other platforms.
Botio solves this problem by introducing a unified abstraction layer.
Instead of writing platform-specific code, you write your business logic against a common interface.
Your bot should not care where a message came from.
This:
if platform == "telegram":
...
elif platform == "rubika":
...
elif platform == "bale":
...should not exist inside your handlers.
Instead, Botio normalizes incoming updates into a unified structure.
Platform Payload
↓
Adapter
↓
Update
↓
Context
↓
Handler
↓
Response
↓
Adapter
↓
Platform API
Your handlers receive a platform-independent context and can focus entirely on business logic.
- Platform-independent bot architecture
- Unified Update model
- Unified User, Chat and Message models
- Adapter-based design
- Async-first architecture
- Extensible platform support
- Framework agnostic
- Simple handler registration
Botio is currently in its early stages of development.
The project is focused on building a clean foundation that can support multiple messaging platforms through adapters.
Supported and planned platforms include:
- Telegram
- Bale
- Rubika
- Eitaa
- Discord
- Custom adapters
pip install botiofrom botio import BotKit
bot = BotKit()
bot.add(
platform="telegram",
token="YOUR_TOKEN",
)
@bot.message
async def echo(ctx):
await ctx.reply(
ctx.message.text
)A normalized representation of an incoming event.
Provides access to the update and helper methods such as replying to messages.
Responsible for translating platform-specific payloads into Botio updates and converting Botio responses back into platform API calls.
Routes updates to the appropriate handlers.
- Keep business logic platform independent
- Hide platform-specific complexity
- Keep the core lightweight
- Avoid framework lock-in
- Make adapters easy to build
- Provide a consistent developer experience
- Core architecture
- Adapter system
- Telegram adapter (MVP)
- Command handlers
- Middleware system
- Filters
- State management
- Storage backends
- Bale adapter
- Rubika adapter
- Eitaa adapter
- Webhook utilities
Contributions, ideas, bug reports, and pull requests are welcome.
MIT