A developer toolkit for the Kick live-streaming platform · Library design and implementation
KickForge: two streaming protocols behind one pip install
Turn the OAuth, WebSocket and webhook plumbing for stream bots into one install-and-auth toolkit, with no public URL.
- time to bot
- ~2 min, 3 steps (install, auth, run)
- packages
- 5 modular (core, bot, clip, gsi, overlay)
- distribution
- one PyPI package
- version
- v0.3.0 live
- public url needed
- none
- Pusher WebSocket
- OAuth 2.1 + PKCE
- EventBus
- Python / PyPI
Problem
Anyone building an interactive bot, an overlay, or clip automation on a live-streaming platform ends up rewriting the same infrastructure every time: OAuth, WebSockets, webhooks, API glue. Streamers and tool builders should be spending their attention on content and behavior, not on re-solving the transport layer from scratch on every project.
KickForge packages that plumbing once so the rest can be built on top of it.
Constraint
The platform splits reading and writing across two different protocols.
Chat runs over a Pusher WebSocket, so reading messages means holding a live WS connection. But sending a message needs a user token obtained through OAuth 2.1 with PKCE, over REST. So a working bot has to speak two protocols at once, read over Pusher WS and write over authenticated REST, and present them as one coherent stream of events.
The extra constraint was that it had to run without ngrok or a public URL. Requiring a publicly reachable webhook endpoint would put the toolkit out of reach for exactly the solo streamers it was meant to serve.
Architecture decision
The design unifies the two protocols behind a shared EventBus.
Reading connects directly to the Pusher WebSocket. Writing goes through an OAuth PKCE token exchange. Both sides publish to and consume from one EventBus, so a consumer of the library sees a single stream of events and never has to know that reads and writes travel different paths.
Because the read side connects out to Pusher rather than waiting for inbound webhooks, there is no webhook server to host and no public URL to expose. The whole setup collapses to a pip install plus an auth command.
Result
Going from nothing to a running bot is three steps and about two minutes: install, auth, run. The toolkit ships as five modular packages, core, bot, clip, gsi, and overlay, under a single PyPI package, with v0.3.0 live.
The unlock is that a two-protocol, auth-gated, normally webhook-hosted integration became something a solo builder installs and runs locally, with the read and write paths hidden behind one event stream.