Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[RFC] Agent Contacts: cross-owner A2A conversations + decision inbox

Abierto
  • ¿Algo no está bien?
#41 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend-api-design, frontend, security, testing-qa

Línea de trabajo

The issue names no files or existing tests. Start by reviewing the existing human review cards, Spaces and revision-aware content, per-Dot permissions, persistent work state, and AG-UI surfaces. Define the local contact/revocation model, disclosure card, fixture peer, durable inbox/outbox states, and restart plus duplicate-submit tests before connecting a live A2A peer.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

I’d like OpenDots to support a simple cross-owner workflow:

“Ask my friend’s agent for a shareable update, let the agents handle bounded clarification, and only interrupt us when a human decision is required.”

This is different from same-workspace multi-agent orchestration. The remote agent belongs to another person, with its own memory, tools, credentials, and policy.

Full downstream design: https://github.com/kvnloo/OpenDots/issues/13

Product shape: Agent Contacts

A contact would represent an owner-confirmed remote agent endpoint.

Initial flow:

  1. Pair — both owners manually confirm the endpoint over an existing trusted channel.
  2. Propose — from a Dot conversation, stage a request to that contact.
  3. Review disclosure — show the exact outgoing text and explicit page/snapshot revisions before sending.
  4. Remote owner decides independently — their deployment controls what its agent may reveal.
  5. Agents clarify within bounds — only approved exchange context is available.
  6. Surface a compact result / blocker card — collapse routine agent chatter; show human decisions when new authority or private context is needed.
  7. Revoke — immediately prevent future local dispatch/continuation.

Initial scope: one-to-one, text-only, read-only exchanges. No computer control, external writes, payments, calendar actions, attachments, groups, public directory, or contact-of-contact forwarding.

Important architecture boundary

OpenDots should implement this independently. It should not require Hermes as a backend.

The app would own its own:

  • contacts registry
  • owner-authenticated pairing/revocation
  • peer authentication/policy
  • durable inbox/outbox
  • disclosure decisions
  • restricted exchange runner
  • delivery/result UI

Hermes can be one compatible contact, not the control plane.

The companion Hermes implementation is separately proposed as a standalone plugin:
https://github.com/kvnloo/hermes-agent/issues/426

Reuse existing OpenDots / CopilotKit surfaces

OpenDots already has several pieces that fit this UX:

  • human review cards
  • Spaces / revision-aware content
  • persistent work state
  • per-Dot permissions
  • AG-UI rendering
  • explicit computer controls

CopilotKit/AG-UI also has A2A middleware support, so I’d evaluate that rather than inventing another agent transport. But A2A connectivity alone does not solve cross-owner authorization, disclosure, isolation, durable delivery, or owner identity.

The contacts policy/outbox must remain server-side and authoritative regardless of whether a request is proposed from text, voice, UI, or by the model.

Security invariants

OpenDots’ current security doc correctly describes the prototype as single-owner. I’d keep that property: two separately owned OpenDots deployments communicate through a narrow peer interface rather than turning one deployment into a shared multi-user workspace.

For the first implementation:

  • pairing grants communication, not Space/computer access
  • remote display names are not verified human identity
  • initial outgoing text is itself a disclosure requiring review
  • approvals bind to recipient + exact content/snapshot revision + expiry/policy epoch
  • the peer runner sees only approved snapshots + exchange transcript
  • no normal thread history, Automatic Learning, browser, shell, computer tools, arbitrary URL fetching, or further delegation
  • remote messages are untrusted data, never authority or UI actions
  • peer task/history operations are ownership-checked
  • delivery state, agent state, and owner-decision state remain distinct
  • revocation blocks future local work but does not claim to erase already delivered data

First mergeable slice

I would avoid starting with a full social/contact network.

The first vertical slice could be:

  • local contact + revocation model
  • owner-only control API
  • one disclosure decision card
  • deterministic fixture peer / no live model dependency
  • durable inbox/outbox state
  • narrow-screen + keyboard-accessible UI
  • clear states for queued / dispatched / peer accepted / reply received / unknown / expired / failed
  • restart + duplicate-submit tests

Then connect a real A2A peer once the policy and state machine are proven.

Interop contract

The Hermes and OpenDots tracks can share only a small versioned behavior contract / fixture set:

  • exchange request
  • approved shared-context snapshot
  • local decision record
  • delivery/result receipt

Each runtime keeps its own storage, policy, UI, and release cadence.

The useful test matrix is:

  • OpenDots ↔ OpenDots works with Hermes absent
  • Hermes ↔ Hermes works with OpenDots absent
  • OpenDots ↔ Hermes matches the same observable fixtures
  • generic A2A peers either get an explicitly approved manual exchange or a clear incompatibility; no silent downgrade to unrestricted behavior

Credit / provenance

This proposal is intended to compose with existing work, not overwrite it.

  • @whatisthis666 proposed separating permission to communicate from permission to read/act in Hermes #126407; @vanscodex has claimed implementation there. That capability distinction directly informs the cross-owner boundary here.
  • @csigelo proposed the optional peer-authentication direction in Hermes #131484; stronger identity can compose later, but this RFC does not depend on it.
  • The broader downstream OpenDots handoff RFC preserves @Chebaleomkar’s peer-tool investigation, @findigital’s file-handoff problem, @charan-rathore’s recurring-work direction, and @vaheed’s watcher direction as separate lanes. This proposal should re-check those owner threads before touching overlapping surfaces.
  • Existing OpenDots/CopilotKit/AG-UI contributors provide the application, review-card, state, and protocol foundation.

I’m happy to prototype this in small slices if the product direction fits OpenDots.

Prepared with AI assistance; this is a proposal, not a claim that cross-owner agent contacts are already implemented.

Lenguaje dominante
TypeScript
Estrellas
2.8k
Forks
344
Merge medio
7 h 8 min
PR fusionados (30 d)
10

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de CopilotKit/OpenDots

Todos los issues de CopilotKit/OpenDots

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.