From f4cf8abe4d772ac85c8ba6d030fc2e1a3d83246c Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 11 Oct 2026 20:22:37 +0200 Subject: [PATCH] Add INTENT and Coulomb Social Telegram community playbook Co-Authored-By: Claude Opus 5.5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 1370019@bnt-lap001 Assistant-Session: d462dd63-16de-4189-ae70-b9cd6566bf87 --- INTENT.md | 240 +++++ ...-CoulombSocialTelegramCommunityPlaybook.md | 963 ++++++++++++++++++ 2 files changed, 1203 insertions(+) create mode 100755 INTENT.md create mode 100755 history/260809-CoulombSocialTelegramCommunityPlaybook.md diff --git a/INTENT.md b/INTENT.md new file mode 100755 index 0000000..7728882 --- /dev/null +++ b/INTENT.md @@ -0,0 +1,240 @@ +# INTENT.md — telegram-edge + +## Purpose + +`telegram-edge` provides the Telegram-facing interface layer for the Coulomb.social ecosystem. + +Its purpose is to make Telegram usable as a primary **social surface** for publishing, community interaction, automation, and service access while keeping Coulomb-controlled systems authoritative for identity, knowledge, content, product logic, and durable state. + +The repository exists to isolate Telegram-specific capabilities, constraints, and protocols behind a controlled edge so that Coulomb and HelixForge can use Telegram deeply without becoming structurally dependent on it. + +--- + +## Primary Utility + +`telegram-edge` should enable Coulomb.social and related systems to: + +- publish and distribute content through Telegram channels, groups, communities, and bots; +- receive and normalize relevant interactions originating from Telegram; +- support conversational and command-based access to Coulomb and HelixForge capabilities; +- expose selected services through Telegram-native interaction patterns, including bots and Mini Apps where useful; +- connect Telegram identities to Coulomb identities without making Telegram the identity authority; +- support community operations such as discussions, topics, moderation, notifications, feedback, and membership flows; +- provide a controlled boundary for automation and agent participation; +- preserve observability, auditability, consent, and policy enforcement at the platform edge; +- make Telegram replaceable or complementable by other social surfaces over time. + +--- + +## Intended Users + +Primary users are: + +- Coulomb.social community members interacting through Telegram; +- maintainers and community operators publishing or moderating through Telegram; +- Coulomb and HelixForge services that need to send or receive Telegram interactions; +- automation and software agents acting through explicitly permitted Telegram interfaces; +- developers integrating Telegram capabilities without coupling domain systems directly to Telegram APIs. + +--- + +## Strategic Role in the System + +`telegram-edge` is an **edge adapter and social interface boundary**. + +It should translate between Telegram-native concepts and Coulomb-native capabilities while preventing Telegram-specific assumptions from leaking into the wider ecosystem. + +Conceptually: + +```text +People / Telegram Clients + │ + ▼ + Telegram Platform + │ + ▼ + telegram-edge + │ + ┌──────┼────────┐ + ▼ ▼ ▼ +Content Identity Services + │ │ │ + └──────┴────────┘ + │ + ▼ + Coulomb / HelixForge +``` + +Coulomb-controlled systems remain the source of truth. Telegram is treated as a powerful but external interaction and distribution environment. + +--- + +## Responsibilities + +`telegram-edge` owns responsibility for: + +1. **Telegram integration** + - Bot API integration; + - channel, group, topic, community, and message interaction; + - Telegram login and identity-linking integration where adopted; + - Mini App integration boundaries where adopted; + - Telegram-specific payment or monetization interfaces where adopted. + +2. **Publishing** + - transforming canonical Coulomb content into Telegram-compatible publications; + - scheduling, updating, linking, and tracking publications; + - preserving references back to canonical content where appropriate. + +3. **Inbound interaction** + - receiving Telegram updates and events; + - validating and normalizing them; + - mapping them into platform-independent commands, events, requests, or contributions. + +4. **Community interface** + - supporting moderation, feedback, discussions, subscriptions, notifications, and community workflows; + - exposing Telegram capabilities without embedding community policy into Telegram-specific code. + +5. **Automation boundary** + - providing explicit interfaces for bots and agents; + - separating automated behavior from human identity; + - enforcing permissions, rate limits, consent, and traceability. + +6. **Platform risk containment** + - isolating Telegram API changes and platform constraints; + - limiting unnecessary retention of Telegram-originated data; + - supporting export, replay, reconciliation, and migration where practical; + - preventing Telegram from becoming an accidental system of record. + +--- + +## Strategic Boundaries + +### In Scope + +`telegram-edge` is responsible for the **translation, integration, and operational boundary** between Telegram and Coulomb-controlled systems. + +It may contain: + +- Telegram API clients and webhooks; +- message and event adapters; +- publication pipelines; +- Telegram-specific rendering; +- identity-link mappings; +- bot command routing; +- Mini App integration endpoints; +- moderation adapters; +- telemetry and delivery evidence; +- platform capability discovery; +- Telegram-specific configuration and policy enforcement. + +### Out of Scope + +`telegram-edge` should not become: + +- the canonical content repository; +- the canonical knowledge store; +- the authoritative user or organization directory; +- the primary business-logic layer; +- a general-purpose social network backend; +- the canonical community governance system; +- an unrestricted archive or scraper of Telegram conversations; +- an AI training corpus derived from Telegram activity; +- a replacement for domain services already owned elsewhere in the Coulomb or HelixForge ecosystem. + +Where durable state is required, the authoritative representation should normally live outside Telegram and outside this repository. + +--- + +## Design Principles + +### 1. Telegram is a Surface, Not the System + +The value of Telegram lies in reach, interaction, convenience, and native social capabilities. + +Core knowledge, identity, product state, and business logic remain under Coulomb control. + +### 2. Keep Platform Coupling at the Edge + +Telegram-specific identifiers, API structures, limits, formatting rules, and lifecycle behavior should terminate inside `telegram-edge`. + +Downstream systems should consume stable Coulomb-native interfaces wherever practical. + +### 3. Canonical First, Publish Second + +Important content should be created or persisted canonically before or alongside publication to Telegram. + +A Telegram post may be a complete user experience, but it should not silently become the only durable copy of strategically important information. + +### 4. Bidirectional, but Deliberate + +Telegram should support both outbound publishing and inbound participation. + +Inbound information should cross into canonical systems only through explicit, inspectable flows with appropriate validation, classification, consent, and provenance. + +### 5. Human and Agent Participation Are First-Class but Distinct + +The edge should support people, bots, and software agents while preserving clear identity, authorization, attribution, and audit boundaries between them. + +Automation should never depend on pretending to be an ordinary human participant. + +### 6. Consent and Data Boundaries Are Explicit + +Telegram-originated data should only be retained, promoted into knowledge systems, or exposed to automated processing when there is a defined purpose and lawful basis. + +Content intended for AI-assisted processing, reuse, or knowledge promotion should have an explicit path rather than being harvested indiscriminately from community activity. + +### 7. Prefer Capability Detection Over Assumption + +Telegram evolves quickly. + +Integrations should model platform capabilities explicitly and degrade gracefully when capabilities, permissions, limits, or commercial terms change. + +### 8. Operations Must Be Observable + +Important inbound and outbound interactions should be traceable through logs, correlation identifiers, delivery state, errors, retries, and relevant platform identifiers without collecting unnecessary personal data. + +### 9. Failure Must Not Corrupt Canonical State + +Telegram outages, API failures, rate limits, deleted messages, changed permissions, or account restrictions must not compromise authoritative Coulomb state. + +Publishing and interaction flows should be retryable and, where appropriate, idempotent. + +### 10. Preserve Exit Options + +The architecture should make it possible to add or replace social surfaces such as web, RSS, email, ActivityPub, Matrix, Discord, or future platforms without redesigning Coulomb's core systems. + +--- + +## Maturity Target + +The long-term target is a **production-grade social edge** through which Telegram can function as a primary community and interaction surface for Coulomb.social while remaining an external, replaceable platform. + +A mature `telegram-edge` should provide: + +- reliable bidirectional integration; +- consistent publication workflows; +- identity-aware interaction; +- secure bot and agent access; +- auditable community automation; +- explicit consent and data-handling controls; +- measurable delivery and interaction state; +- resilience against Telegram API and policy changes; +- clean interfaces to canonical Coulomb and HelixForge services. + +--- + +## Guiding Statement + +> **Use Telegram deeply as a social surface without allowing Telegram to become the system.** + +`telegram-edge` should make Telegram feel native to the Coulomb.social community while preserving the sovereignty, portability, and architectural integrity of the ecosystem behind it. + +--- + +## Stability Note + +This file describes the intended role and enduring architectural purpose of `telegram-edge`. + +**INTENT is stable and aspirational. SCOPE is actual and evolutionary.** + +Implementation choices, supported Telegram features, APIs, workflows, deployment models, and current limitations belong in the repository's evolving scope, architecture, specifications, and work plans. They may change without changing this intent as long as `telegram-edge` continues to provide a controlled, replaceable Telegram social boundary for the Coulomb.social ecosystem. diff --git a/history/260809-CoulombSocialTelegramCommunityPlaybook.md b/history/260809-CoulombSocialTelegramCommunityPlaybook.md new file mode 100755 index 0000000..c6716f3 --- /dev/null +++ b/history/260809-CoulombSocialTelegramCommunityPlaybook.md @@ -0,0 +1,963 @@ +# Coulomb.social Telegram Community Playbook + +**Version:** 0.1 +**Purpose:** Build a durable Coulomb.social community using Telegram as its primary social surface while keeping Coulomb-controlled systems authoritative for knowledge, identity, projects, and products. + +--- + +## 1. Community Thesis + +The Coulomb.social Telegram community should not primarily be an audience for announcements. + +It should become a place where people can: + +**discover → follow → discuss → contribute → collaborate → build → become stewards** + +The distinctive proposition is therefore not: + +> Join our Telegram channel for Coulomb updates. + +It is: + +> **Join a community where ideas are explored openly, turned into working artifacts, and eventually become software, knowledge, and products.** + +Telegram provides the low-friction social environment. Coulomb provides persistence, structure, provenance, and productive infrastructure. + +--- + +# 2. The Community Flywheel + +The central operating loop should be: + +```text + ┌─────────────┐ + │ PUBLISH │ + │ ideas/builds│ + └──────┬──────┘ + │ + ▼ + ┌───────────────┐ + │ DISCUSS │ + │ react/question│ + └───────┬───────┘ + │ + ▼ + ┌───────────────┐ + │ CONTRIBUTE │ + │ ideas/evidence│ + │ code/testing │ + └───────┬───────┘ + │ + ▼ + ┌─────────────────┐ + │ PROMOTE │ + │ into Coulomb │ + │ knowledge/work │ + └────────┬────────┘ + │ + ▼ + ┌───────────┐ + │ BUILD │ + │ prototype │ + │ research │ + │ product │ + └─────┬─────┘ + │ + ▼ + ┌────────────────┐ + │ DEMONSTRATE │ + │ result/lesson │ + └────────┬───────┘ + │ + └──────────────► PUBLISH +``` + +**The most important conversion is not subscriber → customer.** + +Initially it is: + +**reader → participant → contributor.** + +Commercial relationships can emerge later from useful participation. + +--- + +# 3. Start With a Minimal Telegram Topology + +Do not begin by constructing fifteen channels and groups. + +Begin with three surfaces. + +```text +Coulomb.social Community +│ +├── Coulomb.social +│ PUBLIC CHANNEL +│ publishing / discoveries / releases +│ +├── Coulomb Commons +│ PUBLIC GROUP +│ conversation / questions / collaboration +│ +└── Coulomb Bot + INTERFACE + navigation / onboarding / services / automation +``` + +Telegram channels support broadcasting to unlimited audiences, while groups can grow to 200,000 members. Groups can use Topics to organize separate discussions with their own media, notifications, polls, pinned messages and bot participation. + +Telegram Communities, introduced in July 2026, can now link several groups, channels and bots around one subject so members can discover and join the associated spaces. This makes a future multi-space Coulomb structure practical without requiring that complexity on day one. + +--- + +# 4. Give the Three Surfaces Different Jobs + +## Coulomb.social Channel — Signal + +The Channel answers: + +> **What interesting thing happened?** + +Typical publications: + +- a new idea; +- an interesting discovery; +- a project started; +- a prototype working; +- a repository released; +- an experiment completed; +- a question worth investigating; +- a short essay; +- a demonstration; +- a community contribution; +- an invitation to participate. + +Keep it relatively high-signal. + +People should be comfortable subscribing even if they never participate. + +Use reactions and polls as extremely low-friction participation mechanisms. Telegram supports configurable reactions and polls in channels and groups. + +--- + +## Coulomb Commons — Conversation + +The Commons answers: + +> **What are we thinking and doing together?** + +Initially use only a handful of Topics: + +```text +General +Introductions +Ideas +Building +Research +Coulomb.social +HelixForge +Help & Questions +``` + +Topics should emerge from activity rather than taxonomy. + +Archive or merge quiet topics aggressively. + +Telegram Topics behave as distinct conversations inside a group, which makes them appropriate once several discussions are running concurrently. + +--- + +## Coulomb Bot — Interface + +The bot answers: + +> **What can I do here?** + +Initially it needs very little intelligence: + +```text +/start +/about +/projects +/contribute +/help +/events +``` + +Later: + +```text +/search +/project +/capability +/suggest +/status +/join +/profile +``` + +Telegram's Bot API provides an HTTP interface for bots, supports commands and webhooks, and bots can launch Mini Apps when richer interaction becomes useful. + +The important architectural rule remains: + +> **The bot talks to Coulomb services. It does not become Coulomb.** + +--- + +# 5. Establish the Community Contract + +Before inviting people, publish a short pinned message defining the culture. + +Something approximately like: + +```text +Coulomb.social is a place for exploring ideas by doing things with them. + +You are welcome to: + +• ask questions +• challenge assumptions +• share evidence +• propose ideas +• experiment +• build +• improve existing work +• fork ideas in new directions + +Prefer curiosity over certainty. +Critique ideas rather than people. +Show your work where possible. +Credit contributions. +Make interesting things reusable. + +Conversation here may inspire Coulomb projects, but material is only +promoted into canonical Coulomb knowledge through an explicit process. +``` + +That last sentence matters. + +It establishes a distinction between: + +**conversation** and **contribution**. + +--- + +# 6. Build a Contribution Ladder + +Do not expect new members immediately to submit pull requests. + +Create progressively stronger forms of participation. + +| Level | Behavior | Effort | +|---|---|---:| +| L0 Observe | read | tiny | +| L1 React | reaction / poll | tiny | +| L2 Respond | comment / answer | low | +| L3 Suggest | idea / reference / criticism | low | +| L4 Contribute | structured contribution | medium | +| L5 Collaborate | work on something | high | +| L6 Initiate | start an activity/project | high | +| L7 Steward | help maintain the community | ongoing | + +The system should constantly make the **next step obvious**. + +A publication therefore shouldn't always end with: + +> What do you think? + +Use concrete invitations: + +> Does anyone know an existing project solving this? + +> Which of these three approaches would you test first? + +> Can somebody break this architecture? + +> I need two people willing to try this prototype. + +> Who knows this domain well enough to sanity-check the assumptions? + +Those produce action. + +--- + +# 7. Introduce the Promotion Pattern + +This could become one of Coulomb's characteristic community mechanics. + +A Telegram conversation is ephemeral social activity. + +A valuable contribution can be **promoted**. + +```text +Telegram conversation + │ + ▼ +interesting contribution + │ + ▼ + PROMOTE + │ + ├──► issue + ├──► use case + ├──► research note + ├──► evidence + ├──► project idea + ├──► decision + └──► canonical knowledge +``` + +Eventually `telegram-edge` could expose: + +```text +/promote +``` + +or an admin action: + +```text +Promote to Coulomb → + Idea + Evidence + Issue + Research + Project +``` + +The contributor should see what happened: + +```text +✓ Promoted to Coulomb + +Research Idea #134 +"Telegram as an agent interaction surface" + +Contributor: @alice +Source: Telegram discussion +``` + +This creates an extremely important psychological feedback loop: + +> **My contribution went somewhere.** + +That is much stronger than collecting likes. + +--- + +# 8. Make Attribution Visible + +Community building accelerates when contribution generates reputation. + +Telegram added member tags in March 2026, allowing groups to let participants display configurable labels. + +I would eventually combine Telegram-native labels with Coulomb-derived roles such as: + +```text +Explorer +Builder +Researcher +Maintainer +Contributor +Steward +Founder +Bot +``` + +But avoid creating artificial status hierarchies too early. + +Reputation should primarily arise from **visible work**. + +--- + +# 9. Establish Recurring Rituals + +Community is produced by rhythm. + +I would start with five. + +### Monday — What's Moving? + +Short digest: + +```text +⚡ COULOMB / THIS WEEK + +Building: +→ telegram-edge +→ adaptive-pricing + +Exploring: +→ autonomous development economics + +Question: +→ What should Telegram-native contribution look like? +``` + +### Wednesday — Poke It + +Present one idea or prototype specifically for criticism. + +> **Poke it:** What breaks this idea? + +This creates permission for disagreement. + +### Friday — What Worked? + +Show something tangible. + +```text +✓ code +✓ screenshot +✓ benchmark +✓ document +✓ prototype +✓ experiment result +``` + +Avoid endless futurism. + +### Continuous — Interesting Finds + +Share external papers, repositories, products or developments only when accompanied by: + +> **Why this matters to Coulomb.** + +### Monthly — Coulomb Assembly + +A live voice/video session around: + +```text +What happened? +What did we learn? +What's next? +What should we build? +``` + +Telegram supports voice/video group calls and livestream-style functionality, so these can remain inside the community surface. + +--- + +# 10. Founder-Led Seed Phase — Days 0–30 + +The first goal is **not scale**. + +It is making the place feel alive and intelligible. + +### Before inviting anyone + +Prepare approximately: + +- 5–10 good Channel posts; +- welcome message; +- community principles; +- introductions Topic; +- 3–5 discussion prompts; +- bot `/start`; +- clear Coulomb.social link; +- clear Git/repository links. + +Nobody wants to enter an empty restaurant. + +### Recruit the first people personally + +Invite people who are likely to contribute different things: + +```text +builders +researchers +entrepreneurs +technology people +product thinkers +domain experts +skeptics +friends of the project +``` + +A heterogeneous first 20 useful participants can be substantially more valuable than hundreds of passive subscribers. + +### Founder behavior + +During this phase: + +**respond to almost everything worthwhile.** + +Create the conversational norm yourself. + +Do not automate community where human attention is the valuable product. + +--- + +# 11. Participation Phase — Days 30–90 + +The objective changes from: + +**Bernd publishes** + +to: + +**the community produces activity.** + +Introduce three mechanisms. + +## Community Questions + +Regular questions with bounded responses. + +Example: + +```text +QUESTION + +If you had to demonstrate the value of HelixForge +with one 48-hour build, what would you build? +``` + +## Show Your Work + +Encourage people to share: + +- projects; +- repositories; +- diagrams; +- research; +- failures; +- experiments; +- tools. + +## Suggested Contributions + +Telegram allows subscribers to submit suggested posts directly to channels through channel messaging. That could eventually provide a native submission path for community-authored Coulomb publications. + +A useful pattern would be: + +```text +Commons discussion + ↓ +community contribution + ↓ +editorial selection + ↓ +Coulomb Channel publication + ↓ +credited contributor +``` + +Now community members aren't merely commenting on Coulomb. + +**They are producing Coulomb.** + +--- + +# 12. Builder Phase — Months 3–6 + +Once there is recurring participation, connect discussion directly to making things. + +Introduce **Coulomb Missions**. + +For example: + +```text +MISSION #07 + +Can we build a useful Telegram interface +for browsing Coulomb capabilities? + +Duration: +7 days + +Wanted: +1 Python developer +1 UX thinker +2 testers + +Output: +working prototype + repository + +Join: +#mission07 +``` + +Missions should be: + +- bounded; +- optional; +- achievable; +- visibly completed; +- credited. + +The artifact matters more than the ceremony. + +--- + +# 13. Only Then Split the Community + +Additional spaces should appear when activity demands them. + +Potential later topology: + +```text +Coulomb Community +│ +├── Coulomb.social publishing +│ +├── Coulomb Commons general community +│ +├── HelixForge engineering channel +│ +├── HelixForge Lab builder community +│ +├── Research research discussion +│ +├── Opportunities collaboration / missions +│ +└── Bots + ├── Coulomb Bot + └── HelixForge Bot +``` + +Telegram Communities can then make these individual surfaces discoverable as one coherent community. + +**Do not create this topology in advance.** + +Every new room creates another place capable of looking dead. + +--- + +# 14. Acquisition Strategy + +I would deliberately avoid trying to "grow Telegram." + +Grow **Coulomb**, with Telegram as the destination. + +Primary acquisition surfaces can eventually include: + +```text +coulomb.social +Git repositories +README files +project websites +technical articles +LinkedIn +conferences +personal network +search traffic +other communities +product users +``` + +Each should expose one simple invitation: + +> **Follow what we're building → Telegram** + +For highly engaged visitors: + +> **Build with us → Coulomb Commons** + +The distinction gives you two funnels: + +```text +AUDIENCE FUNNEL + +discover → channel → follow + + +COMMUNITY FUNNEL + +discover → channel → commons → contribute → collaborate +``` + +--- + +# 15. Do Not Measure Community by Subscriber Count + +Build a simple community scorecard in `telegram-edge`. + +### Reach + +```text +channel subscribers +post views +views / subscriber +external referrals +``` + +### Activation + +```text +new subscribers +new Commons members +new member introductions +first reaction +first message +``` + +### Participation + +```text +weekly active readers +weekly active participants +unique contributors +responses per discussion +poll participation +``` + +### Contribution + +```text +ideas submitted +evidence contributed +bugs reported +projects proposed +missions joined +artifacts contributed +``` + +### Promotion + +This may be the uniquely important Coulomb metric: + +```text +Telegram contributions + ↓ +promoted into canonical Coulomb artifacts +``` + +Measure: + +**Promotion Rate = promoted useful contributions / substantive contributions** + +### Retention + +Track: + +```text +30-day returning participants +90-day returning contributors +contributors becoming collaborators +collaborators becoming stewards +``` + +### Community Health + +Watch: + +```text +questions unanswered +spam/moderation events +discussion dominated by one person +ratio of founder/community messages +number of community-initiated threads +``` + +The milestone I would care about most is not: + +> 1,000 subscribers. + +It is: + +> **The community generates useful activity without requiring you to initiate every conversation.** + +--- + +# 16. Use Automation Carefully + +`telegram-edge` should progressively automate mechanics rather than relationships. + +Good automation: + +```text +publication +cross-linking +welcome/navigation +event reminders +project lookup +repository status +mission registration +poll collection +promotion workflow +attribution +moderation assistance +metrics +digests +``` + +Poor early automation: + +```text +fake conversation +automatic generic responses +AI replying to everything +AI-generated engagement bait +automatic praise +mass unsolicited DMs +``` + +Bots should make the community **more capable**, not artificially busy. + +--- + +# 17. Community Governance + +Start very lightweight. + +Three rules are sufficient initially: + +### Open Exploration + +Ideas can be incomplete and challenged. + +### Constructive Opposition + +Challenge claims, architectures and assumptions vigorously; avoid turning disagreement into personal conflict. + +### Explicit Promotion + +Telegram discussion does not automatically become canonical Coulomb knowledge. Promotion into repositories, research, products or datasets is explicit and attributable. + +This last rule is particularly useful given Telegram's current restrictions concerning harvesting platform content for AI/ML purposes. Keeping a deliberate promotion boundary is both architecturally and operationally preferable. + +--- + +# 18. The First 90 Days + +## Days 1–14 — Establish + +```text +[ ] Coulomb Channel +[ ] Coulomb Commons +[ ] Coulomb Bot +[ ] Telegram Community wrapper +[ ] usernames/branding +[ ] welcome message +[ ] community principles +[ ] Topics +[ ] first 10 publications +[ ] telegram-edge webhook +[ ] basic telemetry +``` + +Target: + +**A place worth entering.** + +--- + +## Days 15–30 — Seed + +```text +[ ] personally invite first participants +[ ] run introductions +[ ] start Monday / Wednesday / Friday rhythm +[ ] test polls and reactions +[ ] respond actively +[ ] identify first 5 recurring contributors +``` + +Target: + +**Conversation.** + +--- + +## Days 31–60 — Activate + +```text +[ ] introduce Show Your Work +[ ] introduce Coulomb Questions +[ ] recognize good contributions +[ ] implement /promote prototype +[ ] publish first community-derived Channel post +[ ] run first live Coulomb Assembly +``` + +Target: + +**Contribution.** + +--- + +## Days 61–90 — Produce + +```text +[ ] launch first Coulomb Mission +[ ] connect contribution to Git/project infrastructure +[ ] expose projects through Coulomb Bot +[ ] publish contributor credits +[ ] measure contributor retention +[ ] identify first community steward +``` + +Target: + +**Collective production.** + +--- + +# 19. Milestones + +I would think in behavioral milestones rather than follower milestones. + +### M0 — Broadcast + +People read Coulomb. + +### M1 — Conversation + +People respond to Coulomb. + +### M2 — Community + +People respond to **each other**. + +### M3 — Contribution + +People provide useful material. + +### M4 — Collaboration + +People make things together. + +### M5 — Autonomy + +Members initiate useful activity without Coulomb prompting them. + +### M6 — Ecosystem + +Projects, collaborations, products and communities emerge from interactions between participants. + +That final stage is where Coulomb.social starts behaving less like a website and more like what its name suggests. + +--- + +# 20. The Coulomb Community Operating Loop + +Ultimately I would encode this operating model into `telegram-edge`: + +```text +┌──────────────────────────────────────────────┐ +│ COULOMB │ +│ │ +│ ideas → research → projects → products │ +│ ▲ │ │ +└──────────┼───────────────────────┼───────────┘ + │ PROMOTE │ PUBLISH + │ ▼ +┌──────────┼───────────────────────────────────┐ +│ │ TELEGRAM │ +│ │ │ +│ contribution ← discussion ← discovery │ +│ │ ▲ │ +│ ▼ │ │ +│ collaboration ─────┘ │ +└──────────────────────────────────────────────┘ +``` + +The strategic objective is: + +> **Telegram makes Coulomb socially permeable.** + +People should be able to encounter an idea with almost zero commitment, react with one tap, join a conversation with one sentence, contribute something useful with a few minutes of effort, and — if they want — progressively cross the boundary into research, software, products, or community stewardship. + +`telegram-edge` then becomes much more than an API adapter. + +It becomes the machinery that turns a **social interaction surface into an entrance to the Coulomb ecosystem**. \ No newline at end of file