Engineering deep dives, industry perspective, implementation notes, and practical recipes.
Search covers titles, summaries, tags and full article text.
Field notes on the Telegram channel integration for KDCube Companion: a Telegram webhook for messages, a Telegram Mini App for UI, and Connection Hub linking the Telegram actor to a KDCube platform identity through an explicit edge. The Telegram actor stays telegram_ ; platform authority, economics, and identity-family are projected only through select...
An external client speaks MCP and wants a KDCube service. The lazy answer — a shared secret — fails the moment you ask whose data it acts on, what it may do, who pays, and how to turn one connection off. KDCube's answer is a delegated credential: a bearer KDCube issues, scopes to one resource, narrows to consented tools and grants, and records back to the...
A user's memory here is not one store but three folds , each a different aspect: mem holds curated durable entities (what is true), conv records the temporal stream with its production context (what happened, when & where), and cnv gathers cross-world references on a focus board (what is kept at hand). Formed differently, meaning different things, designe...
Your MCP handler should never see an unauthorized call. A managed surface declares its auth in descriptors; one shared Connection Hub guard then runs a fixed sequence of fail-closed checks — credential valid → authority → resource (exact) → tool allowed → grants present → tool consented — before the bundle handler is ever called. This Deep piece walks the...
You have an external app and you want it to reach one KDCube service. Connecting it issues a delegated credential — carrying only the resource grants and selected operations/tools you approved, recorded as a durable consent edge that keeps the app as its own actor and you as the grantor. This Deep piece walks the connect → consent → delegated-credential f...
The same person is not the same as one user_id . They arrive through many channels, each with its own verified identity. The platform keeps those ids separate , links them into a family , and asks two different questions of that family: who is this for? and what may this execution do? This Deep piece defines the foundational vocabulary the rest of the Con...
Named services teach agents progressively: persistent intro, on-demand about, and a recursive schema that expands one exact contract.
The named-services discovery service is the registry that lets a consumer find and reach a namespace published by another app — by namespace, not by hardcoded address . An owner app publishes its complete current provider registry; consumers resolve an eligible provider for each request, across app packages.
The browser control plane where independent app surfaces become one workspace: mounted widgets, claimed events, context drag, provider-owned actions.
An app owns a realm — task:, mem:, cnv: — with its own schema, search, actions, and rendering. Named services let any hosted agent enter that realm without learning any of its private domain rules. The agent gets one generic interface; the provider remains the owner of meaning. This Deep piece walks the four agent surfaces, the pull/read materialization p...
Expose your app's domain as a realm with canonical refs, recursive capability discovery, governed actions, and independent API, MCP, event, job, UI, and agent surfaces.
Objects from many apps sit together on one board without merging their databases. Every durable card is a proxy: canvas owns the card; the provider named by the ref owns the object.