Simple Robot is a Kotlin Multiplatform event framework for bot platforms, and Java callers can use it

One event model across several chat platforms

Simple Robot is a Kotlin Multiplatform, coroutine-based, bot-style event scheduling framework, described by its own description as asynchronous, high performance and Java friendly, and referred to as simbot throughout the documentation.

The premise is that a bot application has the same shape regardless of which platform it talks to. You register a bot, you listen for events, you send messages back. What differs between platforms is the wire protocol and the shape of a channel, a guild and a user. Simbot's contribution is to define one vocabulary for those concepts and let a component library fill in the platform specifics.

The library structure in the repository makes the layering explicit. There is simbot-api/ for the public API, simbot-commons/ for shared code, simbot-cores/ for the core implementations, simbot-extensions/ for the extension mechanism, simbot-processors/ and internal-processors/ for annotation processing, simbot-logger/ and simbot-logger-slf4j2-impl/ for logging, simbot-gradles/ for the Gradle plugins, and simbot-test/ and tests/ for the test suites. A kotlin-js-store/ directory and the presence of samples/ with a QQ webhook server built on Ktor, on Spring WebFlux and on Spring are the clearest signals that this is a multiplatform project with JVM server use as a first case.

The default branch is dev, and the topic list includes telegram-bot, qq-bot, qq-guild-bot, kook-bot and bot-framework alongside kotlin-multiplatform and kotlin-coroutines.

The 5.0 restructure pulled every component into one repository

The most consequential change to the project is documented in a note near the top of the README: from version 5.0 onward, all stable components maintained by the team are merged into the current core repository and maintained together.

Before 5.0, each platform lived in its own repository. The QQ component was in simple-robot/simbot-component-qq-guild, the OneBot component in simple-robot/simbot-component-onebot, and the KOOK component in simple-robot/simbot-component-kook. After 5.0 they are directories in the same repository, under simbot-component-qq, simbot-component-onebot and simbot-component-kook, all on the dev branch.

For a user this means one clone and one version to track, rather than a set of component artifacts whose versions have to be kept in step. For a maintainer it means one release train, which is the harder half of the trade.

The framework's own stated model is that platform functionality is driven by components: you install different component libraries to gain different functional support. That is the same plugin idea as most bot frameworks, but the components here are first class modules in a Gradle build, and the API surfaces they share are the reason the unified listener code below can work across two platforms without an if statement.

Writing the first bot, from configuration to listener

The README gives a complete example of using the KOOK and QQ components together, and it is worth reading as a whole because it shows the shape of every simbot application.

The entry point builds an application from a configuration block.

suspend fun main() {
    launchSimpleApplication { config() }
        .joinWith { module() }
}

The configuration block installs the platform components.

fun ApplicationFactoryConfigurer<*, *, *>.config() {
    useKook()
    useQQGuild()
}

Then the application is configured, which in the example means registering bots and registering listeners.

suspend fun Application.module() {
    registerBots()
    registerListeners()
}

Bots are registered through a block per platform, and starting is part of the registration.

    kookBots {
        register(...) { ... }.start()
    }

    qqGuildBots {
        register(...) { ... }.start()
    }

The listeners block is where the unification shows. A handler for the generic type, ChatChannelMessageEvent, which the API defines as a common type standing for all sub-channel message events, including the QQ guild public channel message event or the KOOK channel message event.

        listen<ChatChannelMessageEvent> {
            println("context: $this")
            println("context.event: $event")

            EventResult.empty()
        }

And then handlers for the platform-specific types, where process is used instead of listen because no return value is needed.

        process<QGAtMessageCreateEvent> {
            println("context: $this")
            println("context.event: $event")
        }

That is the whole pattern in three shapes: listen for a handler that returns an EventResult, process for one that does not, and a generic type when you genuinely want both platforms.

Why the project describes itself as Java friendly

The description calls simbot asynchronous, efficient and Java friendly, and the claim deserves a specific reading rather than a vague one.

Kotlin Multiplatform means the framework's own code is compiled for several targets, and the repository carries a kotlin-js-store/ directory, which is the lockfile for Kotlin/JS dependencies, so the JavaScript target is a real target and not a plan. That matters for a bot framework, because a JavaScript runtime is how many chat platforms are actually hosted.

The Java friendliness is a different claim. It follows from the design rather than from an extra API: the event model is expressed as interfaces and generic types, the registration functions are ordinary methods, and a Java caller can implement a listener and register it without writing Kotlin. The repository also ships simbot-gradles/, a Gradle plugin set, which is the usual way a Kotlin library is made pleasant to consume from a Java build, and simbot-api/ is published to Maven Central under the love.forte.simbot group, as the badge in the README shows.

The practical question for a Java shop is whether the Java-facing API is documented and stable enough to use directly, or whether you end up writing a thin Kotlin layer. The documentation site at docs.simbot.forte.love and the application manual linked from the README are where to check that, since the README itself gives only the Kotlin example.

Preview releases, a dev branch, and the cost of moving with it

The release history is the part to look at before committing. The three most recent releases are v5.0.0-Preview5 on 2026-08-19, v5.0.0-Preview4 on 2026-07-14 and v5.0.0-Preview3 on 2026-06-26. The last push to the repository was on 2026-10-13.

So the 5.0 line has been in preview since at least June 2026, with roughly fortnightly builds. Nothing has been labelled a stable release, and the default branch is dev rather than main. That is a deliberate choice for a framework whose API is still moving, and it is also a cost: if you depend on it you are tracking a preview line, and the surface you use can change between preview builds.

Two files in the repository root are worth knowing about for a project of this size. PERFORMANCE_TESTING.md is a dedicated document about performance testing, and benchmarks/ is a directory to match, which suggests the asynchronous and high performance claim is measured rather than asserted. qodana.yaml and the Qodana badge point at JetBrains code quality reports in the workflow, and there is a .fleet/ directory for the Fleet IDE configuration, plus a .simbot/ directory that holds project-specific configuration.

The samples/ directory gives you the other half of the picture, since it contains three working webhook servers for QQ, one on Ktor, one on Spring WebFlux and one on Spring. Those are the reference points for how a simbot application is actually deployed, and they are the place to look before writing your own server layer.

LGPL-3.0 and what it means for a closed product

Simple Robot is open sourced under LGPLv3, and the repository carries both COPYING and COPYING.LESSER at the root, which is the standard pairing for the LGPL.

For a bot framework the practical question is what happens when you ship. LGPL is a weak copyleft licence: if you use the library as a library, that is, link against it and ship your own application alongside, your application does not have to be published under the LGPL. The obligations attach to the library itself, and to the case where you modify the library, in which case the modified version has to be made available under the same terms.

The reason it matters more here than for many libraries is that bot frameworks are usually embedded in a product you do not publish. A self-hosted bot service, a customer-facing agent, an internal tool. Under LGPL that is fine as long as the library is used as a library, and the two licence files in the root are what you read to confirm the terms.

I am not giving legal advice here, and the point is only that the licence terms are in the repository rather than somewhere you have to hunt for. The README also carries the full notice text at the bottom.

On the source side, the project is mirrored on Gitee as well as GitHub, which matters if your build environment has trouble reaching GitHub, and the documentation is split across an organisation homepage, a communities page, the application manual and a separate documentation site with API reference.

Where Simple Robot is the wrong choice

Four situations argue against it.

The first is a Java-only codebase that does not want Kotlin in the build. The Java friendliness means you can call the API from Java, but the artefact itself is Kotlin, so you are adding the Kotlin standard library and the Gradle Kotlin plugin to a build that did not have them. For a large Java organisation that is a procurement conversation as much as a technical one.

The second is a single platform. If you only serve one chat platform and that platform has a well-maintained official SDK, the component library for it may be a thin wrapper with an extra abstraction between you and the protocol. The unified event model earns its keep when you serve several platforms, which is what the README's own example shows with KOOK and QQ registered side by side.

The third is a need for a stable release. Preview builds on a dev branch mean you are an early adopter of the API. If you are shipping a product with a support obligation, that is a risk you should price in rather than discover later.

The alternative in the same direction is to write directly against each platform's own SDK and keep a thin adapter layer of your own. The difference in approach is that simbot gives you a common vocabulary for channels, guilds and events across platforms, plus the component libraries so you do not have to write those adapters, at the cost of an abstraction you did not choose and an API still in preview. If your platforms are QQ and KOOK and you expect to add more, simbot is the cheaper route. If it is one platform with an excellent official SDK and a long horizon, the adapter is thinner than the framework.

Editorial conclusion

Simple Robot fits a Kotlin team that has to serve more than one chat platform, since the same listener code can handle events across KOOK and QQ and the components ship from one repository. It does not fit a Java-only shop that wants the framework to be its own SDK, and it does not fit a production deployment that needs a settled release, because the 5.0 line has been published as preview builds with the latest listed as v5.0.0-Preview5 from 2026-08-19. Plan around the `dev` branch, and check the LGPL-3.0 terms in COPYING and COPYING.LESSER before you ship it inside a closed product.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. Project website
3. README
4. Releases
5. simple-robot/simpler-robot on GitHub