coulomb/telegram-edge
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add INTENT and Coulomb Social Telegram community playbook

Browse source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1370019@bnt-lap001
Assistant-Session: d462dd63-16de-4189-ae70-b9cd6566bf87
This commit is contained in:
tegwick 2026-10-11 20:22:37 +02:00
parent c94598687b
commit f4cf8abe4d
2 changed files with 1203 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

240
INTENT.md Executable file
View file

@ -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.

963
history/260809-CoulombSocialTelegramCommunityPlaybook.md Executable file
View file

@ -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 <name>
/capability <name>
/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**.