Status: Entwurfsvorschlag, 2026-10-27. Vorgeschlagene Ergänzung zu RFC-0003; nicht ratifiziert, kein IETF-RFC. RFC-0003 und das aktuelle Governance-Gremium bleiben durch diesen Entwurf unverändert. Diskussionsbackend und authentifizierter HTTP-Adapter haben lokale Tests; tatsächliche Produktionszulassung und formale Annahme sind separate Abnahmefreigaben.
1. Zweck und Befugnisse
Forschern Registrierung über Relcom ID, RFC-Diskussion, konkrete Vorschläge und Feedback ermöglichen und zugleich sicherstellen, dass akzeptierter Protokolltext nur über einen geprüften, genehmigten Pull Request geändert wird. Erhalten bleibt, wer jede Revision vorgeschlagen, geprüft, abgestimmt, seine Position geändert und implementiert hat.
Fünf Befugnisse trennen: vom Anbieter bestätigtes Konto/E-Mail, Portalrollen, Moderation öffentlicher Diskussion, formale Governance-Ratifizierung und GitHub-Merge-/Bereitstellungsberechtigungen. Keine impliziert die anderen. Native AgentID-Erzeugung und Paketweiterleitung bleiben unabhängig von der Portalregistrierung. Bestätigte E-Mail beweist weder rechtliche Identität noch Betreiberunabhängigkeit oder ein Konto je Person. Ein eingetippter GitHub-Login ist keine authentifizierte Identitätsbindung.
2. Öffentliche und private Materialien
RFC-Entwürfe, Entscheidungsprotokolle, geprüfte öffentliche Quellen/Nachweise und Beitragsgeschichte öffentlich lesbar halten. Zugangsdaten, Identitätszuordnung, ausstehende Moderation, Sitzungszustand und Betriebsinfrastruktur bleiben privat. Dieser RFC macht das aktuelle native Laborrepository nicht öffentlich. Die Veröffentlichung von Code/SDK/Testvektoren erfordert separat geprüfte Freigabe und Lizenzentscheidung; keine vollständig offene Implementierung versprechen, bevor sie existiert. Allgemeine Beitragslizenzierung bleibt eine offene Governance-Frage.
3. Rollen und Aufbauphase
Ein verifizierter Teilnehmer reicht ausstehende Kommentare/Vorschläge ein und sieht eigene ausstehende Inhalte. Ein Moderator veröffentlicht/verbirgt mit Begründung und Audit, ohne Autorenworte zu ändern oder Protokolländerungen anzunehmen. Ein Administrator vergibt/entzieht Portalrollen mit Audit. Ein Maintainer prüft konkrete GitHub-Änderungen und bereitet sie unter tatsächlichen Repository-Berechtigungen vor; dieses Portaletikett vergibt weder Zugangsdaten noch umgeht es notwendige Reviews/Checks.
Nach tatsächlicher verifizierter Anmeldung und Registrierung wird der anfängliche Administrator serverseitig anhand des vom Eigentümer beobachteten Projektautorpseudonyms in einer root-eigenen privaten Konfiguration festgelegt. Das Pseudonym muss bereits existieren; rohe Provider-Subjects gelangen nie in Git oder Workflow-Eingaben. Erstanmeldung, angegebene E-Mail, Profilname, clientseitige JSON-Rollen oder eingetipptes GitHub-Konto verleihen keine Privilegien. Der Prototyp speichert ein mit projektspezifischem Schlüssel gebildetes Pseudonym statt öffentlichem rohem Subject oder E-Mail. Das anfängliche Governance-Gremium bleibt der ausdrücklich offengelegte einzelne menschliche Eigentümer; Portalregistrierung vergrößert es nicht.
4. Diskussion und Feedback
Neue Kommentare und Vorschläge beginnen ausstehend und sind nur für Autor und Moderatoren sichtbar. Nur veröffentlichte Einträge sind öffentlich lesbar. Verborgene Einträge werden gewöhnlichen Lesern auch bei erratener ID nicht geliefert. Begrenzten Klartext, stabiles Autorpseudonym, Zeitstempel und Originalinhalt verwenden. Veröffentlichen/Verbergen, Rollenänderungen und Stimmen erzeugen dauerhafte Auditereignisse. Korrekturen sind verknüpfte Folgeeinträge; frühere Positionen nicht stillschweigend umschreiben oder negative Ergebnisse aus der Geschichte entfernen.
Dieser Portalworkflow ergänzt den bestehenden GitHub-Vorschlagsweg aus RFC-0003; er entfernt ihn nicht und erfordert kein Portalkonto zum Lesen der Forschung oder Vorschlagen einer GitHub-Änderung.
Ein authentifizierter Teilnehmer kann je veröffentlichtem Vorschlag eine unverbindliche yes/no/abstain-Stimme abgeben, ersetzen oder zurückziehen. Diese Zahlen ausdrücklich als unverbindlich kennzeichnen. Sie sind weder RFC-0003-Zählung noch Nachweis unabhängiger Menschen oder Befehl zum Zusammenführen, Zugriffsvergeben oder Modellstart. Missbrauchs-/Moderationsberufungen, Aufbewahrung und Kontoduplikate brauchen weitere Richtlinienarbeit.
5. Bindende Entscheidungen und freigegebener PR
Bestehende formale RFC-0003-Abstimmung fortsetzen, bis eine Identitätsbindungs-/Gremiumsänderung separat genehmigt ist. Berechtigte menschliche Mitgliederliste und Quellrevision bei Vorschlagseröffnung festschreiben; mehr als die Hälfte des gesamten Gremiums, das erklärte Zeitfenster und authentifizierte letzte berechtigte Stimmen verlangen, ohne vorzeitige Zustimmung. Modellinstanzen und zusätzliche verifizierte Konten erhalten durch Portalbeitritt keine formalen Stimmen.
Ein Maintainer überführt einen geprüften Vorschlag in einen konkreten GitHub-PR mit Verweis auf genaue Diskussion und vorgeschlagene Revision. Problem, Änderung, Validierung, Zuschreibung und Grenzen erläutern. Protokoll-/Governance-/Zulassungsänderungen erhalten ihre entsprechende formale Ratifizierung vor Annahme. Routinemäßige Fehlerkorrekturen verwenden weiterhin freigegebenen PR und notwendige Checks. Öffentliche Kommentare, Moderationsveröffentlichung und unverbindliche Zustimmung allein ändern keinen RFC-Quelltext.
Main-Branch-Regeln konfigurieren und prüfen, die vorgesehene Reviews/Checks verlangen und ungeprüfte direkte Änderungen verhindern. Tatsächliche Durchsetzung ist eine Repository-Konfiguration und wird weder durch dieses Dokument noch das Backend belegt. In der Aufbauphase mit einem Eigentümer das Fehlen unabhängiger Prüfung offenlegen, statt einen weiteren Prüfer zu erfinden. Endentscheidung, genaue Merge-/Freigaberevision und spätere Neubewertung in der zugeordneten append-only Geschichte protokollieren. Bereitstellungs- und Infrastrukturgenehmigung bleiben separate Freigaben.
6. Prototyp und Abnahme
Der auf der Standardbibliothek beruhende infra/community.py Prototyp implementiert Serversitzungs-Berechtigungsprüfungen, ausstehende/öffentliche Sichtbarkeit, Moderatorveröffentlichung/-verbergung, auditierte Administratorrollenänderungen, unverbindliche eindeutige Stimmen, begrenzte Eingabe-/Raten-/Speichermengen und dauerhafte idempotente Mutationen. Er hat keinen HTTP-Listener, Provider-/GitHub-Token, Netzclient oder ausführbaren Modellpfad. Siehe Community-Workflow für Routen, Grenzen, Zustandsschutz und genauen Integrationsvertrag.
Vor Freigabe muss der Adapter kanonischen HTTPS-Host, exakten Origin/CSRF bei Schreibzugriff, verifizierte AuthService-Identität, Anfrage-/Zeitgrenzen und privates/no-store-Caching durchsetzen. Tatsächlichen Eigentümer erst nach verifizierter Anmeldung über ein vom Betreiber bestätigtes registriertes Pseudonym initialisieren. Echte Anmeldung und ausstehenden/Moderator-/öffentlichen Workflow, Rollenentzug, gleichzeitige Wiederholung, erratene private IDs, feindliches HTML als Text, gefälschte Identität/Rollen, Raten-/Kapazitätsfehler und tatsächliche Branch-Regeldurchsetzung prüfen. Synthetische Modultests sind weder Produktionsfreigabe noch externe Einführung.
Der Prototyp speichert privat eingereichten Text und projektgebundene Pseudonyme; er behauptet weder verschlüsselte Anwendungsinhalte noch kryptografische Kommentarautorenschaft. Der Server authentifiziert Kontoeinreichungen. Exportierte Journale nennen ursprünglichen Sprecher und Protokollierenden und zitieren Review/PR. Aufbewahrung, Löschung/Export, Berufungen und stärkere signierte Beitragsbestätigungen bleiben offen.
7. Gewünschte Entscheidung
Trennung von Diskussion, Moderation, unverbindlichem Feedback und formalen geprüften Änderungen genehmigen; Prüfer-/Branch-Durchsetzung und Datenschutz/Aufbewahrung vor allgemeiner Zulassung festlegen. Jede RFC-0003-Änderung nach dessen aktuellem Verfahren ratifizieren. Bis dahin bleibt dies eine vorgeschlagene Ergänzung; weder aktuelles Gremium noch Produktionszugriff ändern sich durch ihre Existenz.
Originaldokument
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.