[Application][Deferred] Elembra Object Spaces — isolated S3-compatible publishing/storage

[senolcolak]

Architecture status

Potential optional Elembra Application under #196. Canonical Application architecture: #209.

Priority: deferred. Do not block the core Sovereign Business Memory roadmap on this feature.

Product decision

Object Spaces is architecturally valid, but it pulls Elembra toward developer/infrastructure storage. It should be implemented only after:

1. the Application foundation ([Architecture][Phase 1] Implement Elembra Application foundation and Module → Application cutover #210–[Architecture][Phase 2] Implement transactional outbox and durable Integration Events #212) is established; and
2. real user/customer demand justifies making it a supported Elembra Application.

It is not part of Platform Core and is not a dependency of Files, Memory, Chat or Agents.

Goal if/when implemented

Provide controlled S3-compatible spaces for technical publishing use cases such as:

• CI/release artifacts;
• static/CDN assets;
• generic S3 object exchange;
• later package-repository/registry backing where a proper higher-level protocol exists.

Hard boundary with Elembra Files

Object Spaces and native Elembra Files storage are separate domains.

Never allow external S3 clients to mutate native Files internal object/blob/metadata namespaces directly.

Reason:

• Files relies on its own metadata, permissions, versions, audit and Memory publication;
• out-of-band S3 changes would create metadata/blob drift;
• external S3 credentials have materially different semantics from Elembra Principal/resource authorization.

Target:

Elembra Files internal storage
  blobs/... / owned metadata namespaces

Elembra Object Spaces
  dedicated buckets or isolated object-spaces/<tenant>/<space>/...

Isolation must be enforceable, not naming-convention-only.

Application ownership

io.elembra.object-spaces would own:

• Object Space definitions;
• scoped S3 identity/access-key metadata;
• IAM/policy adapter state;
• quotas/usage accounting;
• public-publishing policy;
• Object Space audit state;
• its own migrations/API/authorization.

It uses Core Principal/tenant/workspace context but does not put S3 business logic into Core.

Storage Engine boundary

RustFS can remain the initial S3-compatible storage Engine/provider.

Object Spaces controls the management plane. Bulk object data should flow directly to the S3 endpoint where appropriate rather than proxying all bytes through the Elembra backend.

Never expose RustFS root/admin credentials to users.

Public vs authenticated access

Keep distinct:

Publicly reachable S3 API

Endpoint is internet/network reachable but requests require scoped credentials.

Anonymous/public object publishing

Explicit per-Space/prefix policy allows unauthenticated HTTP/CDN reads.

Do not conflate these in UI or permissions.

S3 identities

Support multiple purpose-specific scoped identities, for example:

release-ci-writer
website-cdn-uploader
readonly-customer-access

Required properties:

• least privilege;
• scope to Space/bucket/prefix;
• optional expiry;
• rotate/revoke;
• secret shown once or stored only through approved encrypted secret reference when automation requires retrieval;
• no access to Files internal storage;
• audited create/revoke/public-policy actions.

Do not expose root storage credentials.

MVP if activated

• create/delete/disable Object Space without affecting Files;
• create/revoke/rotate scoped S3 identity;
• read-only/write-only/read-write/delete policy presets mapped to explicit S3 actions;
• quota/usage visibility;
• authenticated S3 endpoint documentation for common clients;
• explicit public-read publishing toggle only if implemented safely;
• tenant/prefix isolation contract tests;
• audit of management operations;
• health/degraded state through Application manifest.

CDN/package/registry phases

These are separate higher-level capabilities, not “S3 means it already works.”

CDN/static publishing

May add HTTP URL mapping, content type/cache control and explicit public policy.

Debian/Ubuntu repositories

Need a real publisher that generates/signs repository metadata and performs atomic publication/snapshots. Raw S3 is only storage.

OCI/Docker registry

Needs an OCI Registry API such as Distribution using S3 as its backend. Docker clients do not push directly to a generic S3 interface.

Do not expand the first Object Spaces milestone into all three products.

Security/operations

• TLS/reverse-proxy controlled endpoint;
• RustFS admin console not public;
• least-privilege IAM;
• tenant/prefix isolation;
• quota enforcement or explicit unsupported state;
• secret/object-name log redaction where needed;
• public access explicit/revocable;
• management events auditable;
• no Files internal prefixes accessible through Object Space credentials.

Non-goals for first implementation

• replacing Elembra Files;
• allowing external S3 writes into Files metadata/blob namespaces;
• full package repository;
• full OCI registry;
• custom CDN domains/billing/multi-region;
• making Object Spaces a core Elembra dependency.

Activation gate

Before implementation starts, add a brief product justification to this issue showing either:

• concrete customer/user demand; or
• a required Elembra workflow that cannot be served cleanly by Files/Connectors/external infrastructure.

Without that evidence, keep deferred.

Acceptance criteria if activated

• Implemented as an independently owned Application, not Core logic.
• Object Spaces cannot address/mutate native Files internal storage.
• Scoped S3 identities are least-privilege, rotatable/revocable and secret-safe.
• Tenant/prefix isolation has negative contract tests.
• Public object access is distinct from authenticated S3 endpoint reachability.
• Failure/disablement of Object Spaces does not affect Files/Memory/Chat core workflows.