Estado: Propuesta de borrador, 2026-10-27. Enmienda propuesta a RFC-0003; no ratificada, no es un RFC de IETF. Este borrador no modifica RFC-0003 ni el censo de gobernanza actual. El backend de debate y adaptador HTTP autenticado tienen pruebas locales; la admisión real en producción y adopción formal son controles de aceptación separados.
1. Objetivo y autoridades
Permitir que los investigadores se registren mediante Relcom ID, debatan RFC, presenten propuestas concretas y aporten comentarios, asegurando que el texto aceptado solo cambie mediante un pull request revisado y aprobado. Conservar quién propuso, revisó, votó, cambió de postura e implementó cada revisión.
Separar cinco autoridades: cuenta/correo confirmados por proveedor, roles del portal, moderación pública, ratificación formal y permisos de merge/despliegue GitHub. Ninguna implica las demás. Generar AgentID nativos y reenviar paquetes siguen siendo independientes del registro. Un correo verificado no prueba identidad jurídica, independencia del operador ni una persona por cuenta. Un login GitHub escrito por el usuario no es una vinculación autenticada.
2. Material público y privado
Mantener públicos borradores de RFC, decisiones, fuentes/pruebas públicas revisadas e historia de contribuciones. Mantener privados credenciales, asociación de identidades, moderación pendiente, sesiones e infraestructura operativa. Este RFC no hace público el repositorio nativo actual. Publicar código/SDK/vectores requiere una publicación revisada y decisión de licencia separadas; no prometer una implementación abierta completa antes de existir. La licencia general de contribuciones sigue abierta en gobernanza.
3. Roles y arranque
Un participante verificado envía comentarios/propuestas pendientes y ve su contenido pendiente. Un moderador publica/oculta con motivo y auditoría, sin editar palabras del autor ni aceptar cambios del protocolo. Un administrador asigna/retira roles con auditoría. Un mantenedor revisa y prepara cambios concretos en GitHub según permisos reales; esa etiqueta del portal no emite credenciales ni elude revisiones/comprobaciones obligatorias.
Tras acceso verificado e inscripción reales, el administrador inicial se fija en el servidor mediante el seudónimo de autor del proyecto observado por el propietario, en configuración privada propiedad de root. Ese seudónimo debe existir previamente; el subject original del proveedor nunca entra en Git ni en entradas de workflows. Primer acceso, correo facilitado, nombre del perfil, roles JSON del cliente o cuenta GitHub escrita no conceden privilegios. El prototipo almacena un seudónimo derivado con clave del proyecto, no subject ni correo originales públicos. El censo inicial sigue siendo el único propietario humano declarado; registrarse no lo amplía.
4. Debate y comentarios
Los comentarios y propuestas nuevos empiezan pendientes y solo los ven autor y moderadores. Solo las entradas publicadas son públicas. Las ocultas no se devuelven a lectores normales, ni adivinando el ID. Usar texto plano acotado, seudónimo estable, marcas de tiempo y contenido original. Publicación/ocultación, cambios de rol y votos generan auditoría duradera. Las correcciones son seguimientos enlazados; no reescribir posturas anteriores ni quitar resultados negativos silenciosamente.
Este flujo complementa la vía de propuestas GitHub de RFC-0003; no la elimina ni exige cuenta del portal para leer investigaciones o proponer cambios en GitHub.
Un participante autenticado puede emitir, reemplazar o retirar un voto orientativo yes/no/abstain por propuesta publicada. Estos recuentos deben etiquetarse no vinculantes. No son el recuento de RFC-0003, ni prueba de personas independientes, ni orden de fusionar, conceder acceso o ejecutar modelos. Apelaciones de abuso/moderación, conservación y duplicación de cuentas requieren más política.
5. Decisiones vinculantes y control de PR aprobado
Continuar con la votación formal de RFC-0003 hasta aprobar por separado una enmienda de vinculación de identidad/censo. Fijar censo humano elegible y revisión fuente al abrir la propuesta; exigir más de la mitad del censo, la ventana declarada y los últimos votos elegibles autenticados, sin aprobación anticipada. Las instancias de modelos y cuentas verificadas adicionales no obtienen voto formal por incorporarse.
Un mantenedor convierte una propuesta revisada en un PR concreto con enlaces al debate exacto y revisión propuesta. Explicar problema, cambio, validación, atribución y límites. Los cambios de protocolo/gobernanza/admisión obtienen la ratificación aplicable antes de aceptarse. Las correcciones rutinarias siguen usando PR aprobado y comprobaciones. Comentarios públicos, moderación y apoyo orientativo por sí solos no modifican fuentes de RFC.
Configurar y verificar reglas de main que exijan revisión/comprobaciones previstas e impidan cambios directos sin revisar. Su cumplimiento real es configuración del repositorio, no algo establecido por el documento o backend. En el arranque con un propietario, declarar la ausencia de revisión independiente, no inventar otro revisor. Registrar decisión final, revisión exacta de merge/publicación y reconsideraciones en la historia atribuida acumulativa. Despliegue y aprobación de infraestructura siguen siendo controles separados.
6. Prototipo y aceptación
El prototipo de biblioteca estándar infra/community.py implementa comprobaciones de permisos de sesión en servidor, visibilidad pendiente/pública, publicación/ocultación por moderador, cambios auditados de roles, votos únicos no vinculantes, límites de entrada/tasa/almacenamiento y mutaciones duraderas idempotentes. No tiene escucha HTTP, token proveedor/GitHub, cliente de red ni ruta de modelos ejecutable. Véase flujo de trabajo comunitario para rutas, límites, protección de estado y contrato exacto de integración.
Antes de exponerlo, el adaptador debe exigir Host HTTPS canónico, Origin/CSRF exactos para escrituras, identidad AuthService verificada, límites de solicitud/tiempo y caché privada/no-store. Fijar al propietario real solo por un seudónimo inscrito confirmado por operador tras acceso verificado. Probar acceso real y flujo pendiente/moderador/público, revocación de roles, reintento concurrente, ID privados adivinados, HTML hostil tratado como texto, identidad/roles falsificados, fallo de tasa/capacidad y reglas reales de rama. Superar pruebas sintéticas no es aprobar producción ni adopción externa.
El prototipo guarda texto privado enviado y seudónimos con clave del proyecto; no afirma cifrar contenido de aplicación ni autoría criptográfica de comentarios. El servidor autentica los envíos de cuentas. Los registros exportados identifican hablante original y registrador, y citan revisión/PR. Conservación, eliminación/exportación, apelaciones y recibos de contribución firmados más sólidos siguen pendientes.
7. Decisión solicitada
Aprobar la separación de debate, moderación, opinión orientativa y cambios formales revisados; especificar aplicación de revisores/reglas y privacidad/conservación antes de admisión general. Ratificar cambios de RFC-0003 mediante su procedimiento actual. Hasta entonces sigue siendo una enmienda propuesta y su existencia no cambia el censo ni el acceso de producción.
Documento original
Status: Draft proposal, 2026-10-27. Proposed amendment to RFC-0003; not ratified, not an IETF RFC. RFC-0003 and the current governance roster are unchanged by this draft. The discussion backend and authenticated HTTP adapter have local tests; actual production admission and formal adoption are separate acceptance gates.
1. Purpose and authorities
Permit researchers to register through Relcom ID, discuss RFCs, submit concrete proposals and offer feedback while ensuring that accepted protocol text changes only through a reviewed, approved pull request. Preserve who proposed, reviewed, voted, changed their position and implemented each revision.
Separate five authorities: provider-confirmed account/email, portal roles, public discussion moderation, formal governance ratification and GitHub merge/deployment permissions. None implies the others. Native AgentID generation and packet forwarding remain independent of portal registration. Verified email is not legal-identity, operator-independence or one-person-one-account proof. A user-typed GitHub login is not an authenticated identity binding.
2. Public and private material
Keep RFC drafts, decision records, reviewed public source/evidence and contribution history publicly readable. Keep credentials, identity mapping, pending moderation, session state and operational infrastructure private. The current native lab repository is not made public by this RFC. Publishing its code/SDK/test vectors requires a separately reviewed release and licensing decision; do not promise a full open implementation before it exists. General contribution licensing remains an open governance issue.
3. Roles and bootstrap
A verified participant submits pending comments/proposals and sees their own pending content. A moderator publishes/hides with reason and audit, without editing the author's words or accepting protocol changes. An administrator assigns/revokes portal roles with audit. A maintainer reviews and prepares concrete GitHub changes under actual repository permissions; that portal label neither issues credentials nor bypasses required review/checks.
After actual verified sign-in and enrollment, bootstrap administrator is pinned server-side by the owner's observed project author pseudonym in root-owned private configuration. The pinned pseudonym must already exist; raw provider subject never enters Git or workflow inputs. First-login, supplied email, profile name, client JSON roles or a typed GitHub account never confer privilege. The prototype stores a project-keyed pseudonym rather than public raw subject or email. The initial governance electorate remains the explicitly disclosed single human owner; portal registration does not enlarge it.
4. Discussion and feedback
New comments and proposals start pending and are private to their author and moderators. Only published entries are publicly readable. Hidden entries are not returned to ordinary readers, including by guessed ID. Use bounded plain text, stable author pseudonym, timestamps and original content. Publish/hide, role changes and votes produce durable audit events. Corrections are linked follow-ups; do not silently rewrite earlier positions or remove negative results from history.
This portal workflow supplements the existing GitHub proposal path in RFC-0003; it does not remove that path or require a portal account to read research or propose a GitHub change.
An authenticated participant may cast, replace or withdraw one advisory yes/no/abstain per published proposal. Explicitly label these counts nonbinding. They are not the RFC-0003 tally, not proof of independent humans and not a command to merge, grant access or run a model. Abuse/moderation appeals, retention and account duplication need further policy work.
5. Binding decisions and approved PR gate
Continue existing RFC-0003 formal voting until an identity-binding/electorate amendment is separately approved. Pin the eligible human roster and source revision at proposal opening; require more than half of the entire roster, the declared voting window and authenticated eligible latest votes, with no early approval. Model instances and extra verified accounts do not receive formal votes by joining the portal.
A maintainer converts a reviewed proposal into a concrete GitHub PR linking the exact discussion and proposed revision. Explain the problem, change, validation, attribution and limitations. Protocol/governance/admission changes obtain their applicable formal ratification before acceptance. Routine fixes still use an approved PR and required checks. Public comments, moderation publication and advisory support alone cannot change RFC source.
Configure and verify main-branch rules that require the intended review/checks and prevent unreviewed direct changes. Actual enforcement is a repository configuration step, not established by this document or by the backend. In the one-owner bootstrap, disclose the lack of independent review rather than fabricate another reviewer. Record the final decision, exact merge/release revision and subsequent reconsideration in the attributed append-only history. Deployment and infrastructure approval remain separate gates.
6. Prototype and acceptance
The standard-library infra/community.py prototype implements server-session permission checks, pending/public visibility, moderator publication/hiding, audited administrator role changes, nonbinding unique votes, bounded input/rate/storage and durable idempotent mutations. It has no HTTP listener, provider/GitHub token, network client or executable model path. See community workflow for routes, bounds, state protection and the exact integration contract.
Before exposing it, the adapter must enforce canonical HTTPS Host, exact Origin/CSRF for writes, verified AuthService identity, request/time bounds and private/no-store caching. Bootstrap the actual owner only by an operator-confirmed enrolled pseudonym after verified sign-in. Test the real sign-in and pending/moderator/public workflow, role revocation, concurrent retry, guessed private IDs, hostile HTML treated as text, spoofed identity/roles, rate/capacity failure and actual branch-rule enforcement. Passing synthetic module tests is not production approval or outside adoption.
The prototype stores private submitted text and keyed project pseudonyms; it does not claim encrypted application content or cryptographic authorship of comments. The server authenticates account submissions. Exported journal records identify both original speaker and recorder and cite the review/PR. Retention, deletion/export, appeals and stronger signed contribution receipts remain open work.
7. Decision sought
Approve the separation of discussion, moderation, advisory feedback and formal reviewed changes; specify reviewer/branch enforcement and privacy/retention before general admission. Ratify any change to RFC-0003 through its current procedure. Until then this remains a proposed amendment, and neither current electorate nor production access is changed by its existence.