> For the complete documentation index, see [llms.txt](https://docs.inrupt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.inrupt.com/ess/releases.md). # Release Notes ## ESS 3.3.0 (Released 2026-09-10) ESS 3.3.0 adds the Activity Log to the Platform Management service, new account and subscription audit events, and improves audit event delivery reliability and detail. It also removes the service lifecycle audit events. ### Activity Log The [Activity Log](/ess/services/service-platform-management/activity-log.md) is a new API on the Platform Management service that lets applications retrieve recent activity for a user's account. It can be used to build features such as an in-app activity feed showing what has happened across a user's resources, access grants, notifications, and more. Activities are presented using the [W3C Activity Streams](https://www.w3.org/TR/activitystreams-core/) format and served as paginated collections. The API supports filtering by category, event name, and time range, with cursor-based pagination for large result sets. The Activity Log records events across six categories: * **Resource** — resource creation, updates, deletions, and reads * **Access** — access grant, request, and denial lifecycle events * **Account** — account provisioning and deprovisioning * **Notification** — webhook subscription creation and deletion * **DataView** — data view definition and binding operations * **Purge** — account data deletion operations Activities are scoped to the authenticated user's account and are automatically retained for a configurable window (default 30 days). {% hint style="info" %} The Activity Log is distinct from [ESS Audit events](/ess/services/service-auditing.md). The Activity Log powers **user-facing** features such as activity feeds, while Audit events are **operator-facing** and intended for system-level auditing and compliance. {% endhint %} For details, see the [Activity Log](/ess/services/service-platform-management/activity-log.md) documentation. ### Account Audit Events The Platform Management service now emits [audit events](/ess/services/service-auditing.md) for account lifecycle operations — account creation and updates, and administrative account actions — giving operators visibility into account provisioning alongside existing resource and access audit events. ### Subscription Audit Events The Notification service now emits [audit events](/ess/services/service-auditing.md) when WebSocket and webhook subscriptions are created or deleted, providing operators with visibility into subscription lifecycle activity. ### Transactional Outbox for Audit Events All services that publish audit events have migrated to a transactional outbox pattern. Audit events are now written to the database within the same transaction as the operation they record, then delivered asynchronously with retries, improving delivery reliability. ### Richer Audit Events Audit events now include additional context: storage audit events include the canonical storage URI, and Verifiable Credential audit events include the grantee as a structured target. ### Container Timestamp Audit Event Container timestamp updates triggered by changes to child resources now emit **`resource-touched`** rather than **`resource-updated`**. Consumers that relied on **`resource-updated`** to detect child resource activity should subscribe to **`resource-touched`** instead. ### Access Grant Read Operations Auditing Audit events for the Access Grant Service's **`/query`** and **`/verify`** endpoints are now gated by [**`INRUPT_VC_AUDIT_READ_OPERATIONS_ENABLED`**](/ess/services/service-access-grant.md#inrupt_vc_audit_read_operations_enabled), which defaults to **`false`**. Operators who rely on those events need to opt in after upgrading. All other Access Grant Service endpoints remain unconditionally audited. ### Removed: Service Lifecycle Audit Events The **`service-started`** and **`service-shutdown`** audit events are no longer emitted. ## ESS 3.2.0 (Released 2026-07-24) ESS 3.2.0 introduces the Search Service, an optional service that enables full-text and semantic search over Solid Pod content. ### Search Service The Search Service replaces the Query/QPF (Fragments) Service that was removed in ESS 3.0. It supports hybrid (keyword + semantic), keyword-only, and semantic-only search over resources stored in Pods, and indexes content automatically as Pods change — no manual sync is required. The Search Service consists of four cooperating microservices: * **Search**: Query API running at `https://search.`, providing hybrid, keyword-only, and semantic-only search, plus faceted discovery, metadata queries, and index management. * **Ingest**: Indexing pipeline that consumes encrypted Kafka events when Pod resources change, extracts text from supported content types (PDFs, images, Office documents, plain text, HTML, JSON, RDF), generates vector embeddings, and dual-writes to OpenSearch (keyword index) and pgvector (vector index). * **Embedding**: ML inference sidecar that generates 384-dimensional vector embeddings using the BAAI/bge-small-en-v1.5 model. Called internally by the Search and Ingest services over mTLS. * **OCR**: Text extraction service for PDFs (text layer with OCR fallback via RapidOCR) and images. Called internally by the Ingest Service over mTLS. In hybrid mode (the default), search results from BM25 keyword search (OpenSearch) and semantic vector search (pgvector) are merged using Reciprocal Rank Fusion (RRF). When the Embedding Service is unavailable, hybrid searches automatically degrade to keyword-only mode and affected ingest events are queued to the dead-letter queue for replay after recovery. For details, see the [Search Service](/ess/services/service-search.md) documentation. ## ESS 3.1.0 (Released 2026-06-29) ESS 3.1.0 introduces least-privilege database credential separation for PostgreSQL-backed services. ### Database Credential Separation (DML/DDL Split) ESS services that use PostgreSQL now support separate database credentials for schema migrations and application runtime: * **DDL credentials** are used by Flyway at startup to run schema migrations. These users are granted the PostgreSQL master role so that migrated objects remain owned by the `postgres` user. * **DML credentials** are used at runtime for application queries. These users are restricted to `CONNECT`, `USAGE`, `SELECT`, `INSERT`, `UPDATE`, and `DELETE` on the `public` schema only. This separation follows the principle of least privilege: the credentials used during normal operation cannot modify the database schema, reducing the blast radius of a compromised credential. In the default configuration, both sets of credentials reference the same Kubernetes secret — no changes are required to upgrade. The credential split is opt-in. For details on enabling credential separation, see the [3.x Changelogs](/ess/releases/changelog.md). ## ESS 3.0.0 (Released 2026-05-27) ESS 3.0 is a major release that introduces native Identity Provider support, permanent resource identifiers, simplified Access Grant flows, and environment isolation. ### Native Identity Provider Support ESS now supports direct integration with external OIDC-compliant Identity Providers. Clients authenticate with their existing IdP and exchange the resulting token for an ESS Access Token via a token exchange endpoint hosted by the [Platform Management service](/ess/services/service-platform-management/token-exchange.md). The ESS OpenID Broker is no longer required as an intermediary. ### Identifiers ESS assigns permanent, globally unique identifiers to storages, resources, agents, and clients. Resources are now accessible via canonical URIs (`{storage-id}/sc/{resource-id}`) in addition to path-based URIs (`{storage-id}/sp/{resource-path}`). Access Grant issuing and notification subscriptions must use canonical URIs so that access is more stable and secure. ### Simplified Access Grant Flow The UMA service has been removed. Access Grants now serve as receipts — once the resource owner approves an Access Grant, the recipient can retrieve the granted resources directly using their ESS Access Token. ESS checks the grant server-side, so no UMA negotiation or additional token exchange is needed. Additionally, Access Grants are now fully independent of ACP — no VC Matcher policies or ACP enablement configuration is required. This simplifies the access flow, reduces client code complexity, and eliminates a common source of hidden authorization failures. ### Environment Isolation Each ESS service can operate within its own named PostgreSQL database schema. This provides deployment flexibility — all services can connect to a single database instance, or separate database instances can be used for each service. ### Unified User Provisioning All user provisioning — including account creation, WebID management, and storage allocation — is handled through the [Platform Management service](/ess/services/service-platform-management/platform-management-api.md). The Pod Provisioning Service and WebID Service endpoints are no longer called directly by clients. ### Removed Services The following services have been removed in ESS 3.0: * **UMA Service**: Replaced by simplified Access Grant flow with direct resource access * **Query/QPF (Fragments) Service**: Being replaced with new search capabilities * **Notification Gateway Service**: Removed * **WebSocket Notification Service**: Removed; use the Notification Delivery Service ## Changelogs For changelogs, see [3.x Changelogs](/ess/releases/changelog.md).