Research: Plan for releasing public version (gonka-proxy) from private gonka-proxy-service

[mingles-agent]

Background

Context

We have two repos:

• Private (gonka-proxy-service): /root/.openclaw/workspace/gonka-proxy-service → MinglesAI/gonka-proxy-service — основная разработка, все изменения идут сюда
• Public (gonka-proxy): /root/.openclaw/workspace/gonka-proxy → MinglesAI/gonka-proxy — публичная версия, только избранные фиксы вручную

Currently both repos are at the same commit (b73e093). The user has made recent updates to the private repo (locally or on a feature branch) including changes to the signing mechanism.

What the stack does

The proxy is an OpenAI-compatible FastAPI service that:

• Takes API key auth from external clients (API_KEY env var)
• Signs requests to Gonka backend using ECDSA (SECP256k1) with hybrid monotonic timestamps
• Streams responses back to clients

Key files:

• app/main.py — FastAPI app, settings, routes
• app/gonka_client.py — signing logic (_sign_payload, _hybrid_timestamp_ns, _prepare_request)
• app/auth.py — API key verification
• Dockerfile, requirements.txt

Goal

Prepare a concrete migration plan for publishing a minimal working public version from the private repo. Key requirements:

1. No registration — works with just env vars (GONKA_PRIVATE_KEY, GONKA_ADDRESS, GONKA_ENDPOINT, GONKA_PROVIDER_ADDRESS, API_KEY) — no DB, no user accounts
2. Signing mechanism — must include any recent signing changes from private repo (signing currently uses SECP256k1 ECDSA; user mentioned changes to signing mechanism need to be ported)
3. Clean public version — strip any MinglesAI-specific infra details, internal tooling, or sensitive config

Tasks for the architect

1. Diff both repos: Compare MinglesAI/gonka-proxy-service HEAD vs MinglesAI/gonka-proxy HEAD — identify exactly what diverged
2. Review signing mechanism: Examine app/gonka_client.py in private repo — document current signing approach and any recent changes that need to go public
3. Define what goes public: Which files/changes are safe to publish? What must stay private?
4. Migration strategy: How to sync — direct cherry-pick to gonka-proxy, or maintain a clean public branch?
5. Break down into implementation tasks ready for a developer

Local paths

/root/.openclaw/workspace/gonka-proxy-service/   # private
/root/.openclaw/workspace/gonka-proxy/            # public (already cloned)

Focus Areas

• signing mechanism diff
• private vs public classification
• minimal env-only setup
• migration strategy