add-ideas/govoplan-postbox
1
0
Fork 0
Code Issues 13 Pull Requests Actions Packages Projects Releases Wiki Activity

Sync wiki from project files

Albrecht Degering
2026-07-09 15:07:17 +02:00
parent bb6cd5d90e
commit fb97e16838
2 changed files with 26 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
Codex-Project-Index.md

@@ -5,5 +5,4 @@
This page is generated from repository and product-directory project files. This page is generated from repository and product-directory project files.
- [Repo-README](Repo-README) - `/mnt/DATA/git/govoplan-postbox/README.md` - [Repo-README](Repo-README) - `/mnt/DATA/git/govoplan-postbox/README.md`
- [Repo-docs-POSTBOX-BACKLOG](Repo-docs-POSTBOX-BACKLOG) - `/mnt/DATA/git/govoplan-postbox/docs/POSTBOX_BACKLOG.md`
- [Repo-docs-POSTBOX-CONCEPT](Repo-docs-POSTBOX-CONCEPT) - `/mnt/DATA/git/govoplan-postbox/docs/POSTBOX_CONCEPT.md` - [Repo-docs-POSTBOX-CONCEPT](Repo-docs-POSTBOX-CONCEPT) - `/mnt/DATA/git/govoplan-postbox/docs/POSTBOX_CONCEPT.md`

27
Repo-docs-POSTBOX-CONCEPT.md

@@ -1,4 +1,4 @@
<!-- codex-wiki-sync:995fac876969a8a7a228ec7d --> <!-- codex-wiki-sync:acf0243600f0d03c2bb67109 -->
> Mirrored from `/mnt/DATA/git/govoplan-postbox/docs/POSTBOX_CONCEPT.md`. > Mirrored from `/mnt/DATA/git/govoplan-postbox/docs/POSTBOX_CONCEPT.md`.
> Origin: `repository`. > Origin: `repository`.
@@ -13,6 +13,13 @@ GovOPlaN Postbox provides in-platform postboxes that are addressable containers
The key distinction from a mailbox is ownership. A mailbox is usually bound to a login, user credential, or external mail account. A GovOPlaN postbox is bound to platform context: organization, role, process, portal, campaign, or service responsibility. The key distinction from a mailbox is ownership. A mailbox is usually bound to a login, user credential, or external mail account. A GovOPlaN postbox is bound to platform context: organization, role, process, portal, campaign, or service responsibility.
The strategic target is an encrypted administrative postbox. The first
implementation may start with ordinary persisted messages, but the model must
not prevent later end-to-end encryption, role/function key epochs, signed
manifests, external-recipient tokens, or honest retraction semantics. The
cross-module target architecture is recorded in
`govoplan-core/docs/POSTBOX_E2EE_ARCHITECTURE.md`.
## Role-Organization-Bound Access ## Role-Organization-Bound Access
The special access pattern is a postbox linked to an organizational unit and one or more roles. A person can access that postbox while their identity has an effective matching role in that organizational unit. The special access pattern is a postbox linked to an organizational unit and one or more roles. A person can access that postbox while their identity has an effective matching role in that organizational unit.
@@ -94,6 +101,11 @@ Optional consumers:
- Administration of bindings should require explicit postbox administration permission plus access/RBAC authority for the target organization. - Administration of bindings should require explicit postbox administration permission plus access/RBAC authority for the target organization.
- Sensitive access decisions and binding changes should emit audit events. - Sensitive access decisions and binding changes should emit audit events.
- Retention rules should be postbox-owned but able to reference campaign, file, and portal provenance. - Retention rules should be postbox-owned but able to reference campaign, file, and portal provenance.
- Expiry, withdrawal, and retraction UI must distinguish future access control
from already fetched or decrypted plaintext.
- Message metadata should preserve room for ciphertext manifests, wrapped keys,
key epochs, recipient device references, and external capability tokens even
before full E2EE ships.
## First Implementation Shape ## First Implementation Shape
@@ -108,3 +120,16 @@ The WebUI should start as an administration and inbox surface:
- audit-visible administrative actions - audit-visible administrative actions
Campaign, files, portal, and mail behavior should arrive as optional integrations after the core postbox model is stable. Campaign, files, portal, and mail behavior should arrive as optional integrations after the core postbox model is stable.
## E2EE Readiness Checklist
Before the data model is considered stable, verify that it can represent:
- message or attachment ciphertext references
- signed manifest references
- recipient, role, or function key wrapping records
- key epoch and device-key references
- key-fetch/access audit events
- external recipient token state
- expiry and withdrawal state separate from deletion
- retention state that can operate without decrypting content