Client-Centric Query Engines for Bluesky

From Server-centric to Client-centric Data Integration over Decentralized Knowledge Graphs with Personal Query Engines

Enabling Personal, Transparent, and Privacy-Preserving Data Integration

Ruben Taelman

IDLab, Department of Electronics and Information Systems, Ghent University – imec, Ghent, Belgium

Full paper

Context & Problem

Most Web data is centralized in the hands of a few large organizations → raises concerns around privacy, censorship, and data breaches.
Decentralized environments (Solid, Bluesky, Nostr, …) break down data silos, but data integration remains poorly understood.
Today, integration is server-centric: data is extracted and centralized in the cloud, away from the user → sacrifices control, transparency, and privacy.
Goal: shift to client-centric data integration via reusable personal query engines running on the user's device.

Main figure: personal query engine integrating decentralized data sources

A personal query engine runs on the client, reused by multiple apps, and must (1) discover heterogeneous sources, (2) offer control/transparency/privacy, and (3) be fast through context-aware optimization.

Proposed Approach

A personal query engine runs close to the user as a reusable layer between applications and decentralized data sources.
Apps issue declarative SPARQL queries; the engine handles source discovery, federation, and optimization transparently.
The engine is controlled, transparent, and private by design → private data never leaves the user's trusted zone.
Timely due to legislative pressure (GDPR, AI Act) and increasingly powerful client hardware and fast networks (5G, Wi-Fi).

Challenge 1: Client-Driven Query Processing over Heterogeneous Sources

Fundamental understanding of client-driven query processing in a large heterogeneous environment with sources not known upfront.

O1a. Hypermedia-based query shapes

Enable engines to execute queries over interfaces without prior assumptions on their expressivity. Declarative query shapes should allow containment-based query planning.

O1b. Adaptive query planning

Optimize querying over dynamically discovered sources. Publishers signal authority over data shapes; exclusive groups enable assignment to larger subqueries.

O1c. Join/authority-aware link pruning

Reduce the number of links during cross-source traversal by pruning via authority-based subqueries and early-completing join operations.

Challenge 2: Personalized Client-Driven Query Processing

Empowering users with personalized control over client-driven query processing.

O2a. Decentralized Preference Model

Model explicit and implicit user preferences scattered across sources; topical interests, trust relationships, operational settings, and provenance history.

O2b. Preference-Driven Querying

Drive traversal via a preference-based cost model for link pruning and prioritization, and incorporate how/where-provenance into query results to provide insights.

O2c. User-Pattern-Aware Caching

Speed up sequences of similar queries through pattern-aware caching and link prefetching, using partial cardinalities from the cache for query planning.

Challenge 3: Context-Aware Optimization of Client-Driven Query Processing

Making client-centric processing practical through optimization to user-relevant metrics.

O3a. Resource-Aware Cost Model

Optimize execution using surrounding resources: battery, CPU, latency, bandwidth. Adapt the plan dynamically during long-running queries or mobile clients.

O3b. Federated Materialized Views

Reuse executions by other engines over similar public data. Extend RDF views to multiple heterogeneous sources and introduce federated query rewriting.

O3c. Privacy-Aware Query Outsourcing

Outsource computations with privacy preservation via query decomposition across heterogeneous sources, balancing MPC and privacy-agnostic parties.