Data & Credentials

Introduction

This page answers the practical question: what data does OpenKakao actually touch, and where does it cross a trust boundary?

OpenKakao is designed to stay local-first. That only remains true if you understand which parts stay on your machine and which parts leave it.

Local reads

The CLI reads KakaoTalk app state, cache-backed metadata, and saved local credentials when a command needs them.

Local storage

Credentials can be persisted under your home directory so repeated commands do not require a fresh extraction every time.

Network traffic

Commands talk directly to Kakao infrastructure used by the desktop client, including REST, LOCO, and media endpoints.

User-expanded boundary

Hooks, webhooks, LLM APIs, and exports can widen the trust model beyond the local-first base.

The base model is small on purpose

OpenKakao does not introduce a hosted relay or a project-operated cloud API by default. The base model is machine-to-Kakao unless you expand it yourself.

Local Reads

Depending on the command, OpenKakao may read:

KakaoTalk app cache data needed for login extraction
local identifiers and request metadata used to reconstruct authenticated calls
your existing saved credentials from ~/.config/openkakao/credentials.json

Local Storage

The CLI can persist credentials to:

~/.config/openkakao/credentials.json

The project stores this file with 0600 permissions so it is only readable and writable by the current user.

Network Destinations

The CLI is intended to talk to Kakao infrastructure used by the desktop app, including:

katalk.kakao.com
talk-pilsner.kakao.com
booking-loco.kakao.com
ticket-loco.kakao.com
dynamically assigned LOCO servers
Kakao CDN endpoints for media flows

What Is Not the Default Model

No OpenKakao cloud sync

There is no project-hosted service that mirrors your chats or keeps your account traffic on behalf of the CLI.

No message telemetry by default

The intended model does not include remote analytics about your messages, account behavior, or extracted secrets.

No hosted API relay

Your account traffic is not supposed to pass through an OpenKakao backend before it reaches Kakao.

No automatic third-party export

Chat history does not leave the machine unless you explicitly wire it into another system.

By default, OpenKakao does not introduce:

an OpenKakao cloud sync service
remote project telemetry about your messages
a project-hosted API that proxies your account traffic
automatic export of your chat history to third-party services

Your Responsibility

Once you pipe JSON into other tools, the privacy model changes.

Examples:

sending chat data into an external LLM API is your decision
writing exports to shared folders or databases is your decision
forwarding messages to webhooks or bots changes the risk surface immediately

OpenKakao keeps the base model local-first. Your automation stack may not.

The moment you forward, you own the new boundary

Webhooks, remote LLM APIs, shared databases, and bots do not inherit the CLI's local-first posture. They create a new privacy and retention model that you need to evaluate explicitly.

Hook and Webhook Boundary

watch --hook-cmd keeps event handling local by passing normalized JSON to a shell command on the same machine.

watch --webhook-url changes the boundary:

matched event payloads are sent out over HTTP
any destination retention policy now matters
your receiver becomes part of the trust model

If you enable --webhook-signing-secret, requests include:

X-OpenKakao-Timestamp
X-OpenKakao-Signature

This helps receivers verify integrity, but it does not replace transport security, timestamp validation, or receiver-side access control.