A Robust Decentralized Infrastructure for Trust-Aware Open Knowledge Sharing

As with the first-generation network, publishing/retrieval and querying are separated in order to not let the complexity of querying compromise the performance and stability of the publishing and retrieval features. The publishing/retrieval layer is implemented as a federated set of Nanopub Registries, which ingest, validate, and replicate these nanopublications, depending on their digital signatures and Trusty URIs. A set of Nanopub Query services implements the querying layer by retrieving the nanopublications from the Registries, loading and indexing their content in triple stores, and exposing them through SPARQL and REST endpoints. User-facing clients such as Nanodash sit on top of these APIs to let users share, consume, find, and aggregate nanopublications. Figure 1 shows this overall architecture, including a monitor service (on which links to all services on the current network can be found), and the ecosystem test simulation module to be introduced below.

In contrast to the first-generation network, only signed nanopublications are accepted, with reliable revocation and update via retractions and supersessions. Each nanopublication is stored, replicated, and exposed along two axes: primarily by its signing public key (the one attribute that cannot be forged) and secondarily by its declared types. Registry and Query instances can restrict either axis to define their coverage; replication proceeds along these same axes via paginated checksummed lists, and Query services materialise per-agent and per-type repositories. Each Registry is parameterised by a setting nanopublication that defines its trust seed and policies; the resulting trust state is reproducible and transparent, and the same calculation determines publication quotas.

Three core attributes determine how the Registry stores and organizes its nanopublications: the public key used to sign, the agent that controls that key, and the types each nanopublication declares about itself. Every accepted nanopublication moreover carries a signature (currently using RSA) and the respective full public key, which the Registry in hashed form uses as account identifier. Agents are identified by their URIs (typically ORCIDs) and are bound to their keys through declaration nanopublications.

Each nanopublication further declares a set of types (URIs) that place it in a functional or domain class (biodiversity, retraction, declaration, endorsement, template, and so on). A Registry instance has a configurable coverage, defined as a set of types denoting the kind of nanopublications it accepts and replicates.

Three nanopublication types are crucial for the trust layer: a setting nanopublication parameterises a Registry, declaration nanopublications bind agent identifiers to public keys, and endorsement nanopublications add trust edges between such bindings. These three types are always loaded by a Registry, irrespective of its configured coverage. Simplified examples in TriG notation are shown below.

# Common head graph (identical across types):
sub:Head { this: a np:Nanopublication ;
           np:hasAssertion       sub:assertion ;
           np:hasProvenance      sub:provenance ;
           np:hasPublicationInfo sub:pubinfo . }

# (a) Setting assertion: declares the trust root and propagation policy
sub:assertion {
  sub:setting a npx:NanopubSetting ;
    npx:hasAgents              <…initialAgentsIndex> ;
    npx:hasBootstrapService    <https://registry.knowledgepixels.com/> ,
                               <https://registry.nanodash.net/> ,
                               <https://registry.petapico.org/> ;
    npx:hasServices            <…servicesIndex> ;
    npx:hasTrustRangeAlgorithm npx:IDEBT10 ;
    npx:hasUpdateStrategy      npx:UpdatesByCreator . }

# (b) Declaration assertion: binds an agent (e.g. via ORCID) to a public key
sub:assertion {
  sub:keyDecl npx:declaredBy   orcid:0000-0002-7487-4881 ;
              npx:hasAlgorithm "RSA" ;
              npx:hasPublicKey "MIGfMA0GCSqG…wIDAQAB" . }

# (c) Endorsement assertion: approves a declaration nanopublication
sub:assertion {
  orcid:0000-0002-1267-0234
    npx:approvesOf <https://w3id.org/np/RA2rnE4Gi…> . }

# Common provenance and publication info graphs (identical across types):
sub:provenance { sub:assertion prov:wasAttributedTo orcid:0000-0002-1267-0234 . }
sub:pubinfo    { this: dct:created "2025-12-02T12:17:03Z"^^xsd:dateTime .
                 sub:sig npx:hasPublicKey "MIGf…AB" ;
                         npx:hasSignature "VFt…EQI=" ;
                         npx:signedBy     orcid:0000-0002-1267-0234 . }

Incoming nanopublications enter a Registry through an HTTP POST endpoint. The Registry checks the Trusty URI, verifies the signature against the declared public key, checks that the nanopublication's types fall within the instance's coverage, and checks the agent's account and publication quota. If these checks succeed, the nanopublication is accepted and stored in the Registry's MongoDB document store. Their pre-existing Trusty URI is used as internal and external identifier, by which the nanopublication becomes retrievable.

Registries replicate content from one another along the same (pubkey, type) axes they also use for their internal organization. Every (pubkey, type) pair has its own ordered list that is exposed as a paginated HTTP resource. Entries carry a running position and a checksum derived from the Trusty URI hashes of all previous entries via bitwise XOR. Same checksums on different servers thereby always imply the exact same set of entries up to that point in the list, but not necessarily in the same order. This allows peers to detect divergence and resume replication after interruption. An instance therefore does not mirror the entire network: it selects the public keys and types it covers and pulls only the corresponding lists from its peers, alongside the small number of fixed types needed for trust calculation.

Nanopublications are immutable and cannot be unpublished once in the network (but Registries can delete local nanopublications when needed). Retractions are themselves nanopublications that reference, by Trusty URI, the nanopublications they retract. The Registry does not delete the target — every nanopublication remains resolvable by its hash — but it sets an invalidated flag on the corresponding list entry. When the retracted nanopublication is a declaration or endorsement, the invalidation additionally propagates into the next trust-state computation, so that stale keys and edges are removed from the trust graph as part of its normal re-derivation.

Registries only allow for lookup by ID and via the nanopublication lists as explained above. More advanced querying is supported by the independent Nanopub Query instances, which build up on the Registries to incrementally fetch new nanopublications, index them in RDF4J triple stores and make them available for SPARQL-based querying.

A Query instance maintains a family of repositories rather than a single monolithic triple store: global ones (a metadata repository, an optional full repository of all four graphs per nanopublication, and an optional thirty-day sliding window) plus a per-public-key (pubkey_<hash>) and per-type (type_<hash>) repository for every key and type seen, so that narrow queries hit a correspondingly narrow index.

Beyond the raw triples, Query maintains an admin graph (npa:graph) recording signatures, agent URIs, declared types, retraction and supersession links, and load-time metadata (monotonic load counter, per-batch checksum, ingest timestamp), making questions like “everything published since load counter N” expressible as simple SPARQL queries. Trust states from the Registries are materialised into a dedicated trust repository, so authority-sensitive queries (e.g. restricting to signing keys currently approved for a given agent) are expressible as plain locally-federated SPARQL joins.

On top of full SPARQL, Nanopub Query provides custom APIs from SPARQL templates (extending grlc [41], OpenAPI-compliant). The templates are themselves nanopublications, and the API becomes available immediately after publication.

In our open and decentralized setting, a trust algorithm must be robust against open-network adversaries, such as Sybil cliques, fan-out flooding, and unadmitted publishers attempting to inflate computation cost. We therefore need to put solid limits to the direct and indirect influence each identity can exert. The algorithm must also be efficient to compute at the global scale in a federated setting, where trust network calculation should not be restricted to a few powerful nodes. Specifically, we cannot expect a full endorsement network to be available upfront, but the algorithm should load trust edges iteratively and selectively. Finally, the algorithm must be reproducible in the sense of being bit-stable across peers so that the resulting trust state can itself be a content-addressable artefact that downstream services can mirror and if needed verify.

Each Nanopub Registry derives a per-public-key trust score by running IDEBT over three nanopublication types: declarations bind agents to public keys, endorsements add trust edges between such bindings, and retractions invalidate previously declared edges. For simplicity we assume here that each declaration binds exactly one (agent, pubkey) and each endorsement references exactly one declaration. The main loop of the IDEBT algorithm alternates frontier selection with peer fetches and path expansion, as described in this pseudo-code:

Globals:
  peers   — configured peer registries (read-only)
  setting — setting nanopublication (read-only)
  paths   — set of trust paths (filled by IDEBT)

IDEBT():
  paths        ← { (chain = [$], ratio = 1.0, ¬primary) }
  declarations ← { peers.fetch(u) : u ∈ peers.fetch(setting.agentDeclCollection) }
  endorsements ← ∅
  N            ← { ($, (a, k)) : (a, k) declared by some D ∈ declarations }

  for d = 1 to MAX_DEPTH:
    expand ← SelectFrontier(d - 1)
    if expand = ∅: break
    for p in expand:
      k ← pubkey(end(p))
      declarations ← declarations ∪ peers.fetch(k, DECLARE_TYPE)
      endorsements ← endorsements ∪ peers.fetch(k, ENDORSE_TYPE)
      N ← N ∪ { ((a, k), (a', k')) :
                ∃ E ∈ endorsements signed by (a, k),
                ∃ D ∈ declarations referenced by E,
                D declares (a', k') }
    Expand(expand, N)

The algorithm iteratively builds a set of trust paths in the global variable paths. Each trust path p records a chain chain(p) of (agent, pubkey) hops with last hop end(p), a ratio p.ratio ∈ [0,1], a primary flag, and depth length(p) = |chain(p)| − 1; $ denotes the root, with the setting as root endorser. Each Registry maintains local sets of declarations and endorsements fetched from peers, from which the trust-edge set N is derived: ((a, k), (a', k')) ∈ N iff some endorsement signed by (a, k) references a declaration of (a', k'). Frontier selection then picks, per endpoint at the previous depth, the highest-ratio non-primary path above MIN_RATIO:

SelectFrontier(d):
  expand ← ∅
  for x in { end(p) : p ∈ paths, length(p) = d, ¬p.primary }:
    p* ← argmax { p.ratio : p ∈ paths, end(p) = x, length(p) = d, ¬p.primary }
    if p*.ratio ≥ MIN_RATIO:
      expand ← expand ∪ { p* }
  return expand

The argmax above may have ties on p.ratio alone, which can be resolved on a secondary key sorthash = hash(setting ‖ pathId) with pathId a function of chain(p), to maximize (p.ratio, sorthash) instead of just p.ratio. Expansion then splits the parent's ratio: a fraction SELF_SHARE stays on the (now-primary) parent, and the rest is distributed across endorsed children.

Expand(expand, N):
  for p in expand:
    endorsed ← { (a, k) : (end(p), (a, k)) ∈ N,
                          ¬∃ p' ∈ paths : end(p') = (a, k) ∧ p'.primary }
    n_agents ← |{ a : (a, _) ∈ endorsed }|
    for (a, k) in endorsed:
      n_keys ← |{ k' : (a, k') ∈ endorsed }|
      r      ← p.ratio × (1 - SELF_SHARE) / n_agents / n_keys
      paths  ← paths ∪ { (chain(p) · (a, k), r, ¬primary) }
    p.ratio   ← p.ratio × SELF_SHARE
    p.primary ← true

Three properties of IDEBT make its result robust, efficient to compute, and reproducible: ratio mass is conserved, so each pubkey has bounded influence regardless of how many endorsements it issues (Lemma 1); the path set is bounded by the size of the seed plus the number of endorsements loaded, with at most one primary path per agent-pubkey binding (Lemma 2); and execution is deterministic (Lemma 3).

Lemma 1 (Ratio conservation). Throughout IDEBT's execution, ∑p∈paths p.ratio ≤ 1.

Proof. After initialisation, paths contains the root path of ratio 1, so the sum equals 1. Ratios are only modified inside Expand. For each processed path p, the parent ratio drops to SELF_SHARE · p.ratio and each (a, k) ∈ endorsed contributes a child of ratio p.ratio · (1 − SELF_SHARE) / nagents / nkeys. The child weights partition first across agents and then across each agent's keys, so the children's total ratio is exactly p.ratio · (1 − SELF_SHARE) when endorsed is non-empty and 0 otherwise. Hence the per-path change is at most zero (Δp ≤ 0), so ∑ p.ratio is non-increasing across iterations and remains ≤ 1. ∎

Lemma 2 (Bounded path set). Each agent-key binding fix terminology "binding" versus "account" (a, k) is the endpoint of at most one primary path in paths, and the full path set is bounded by |paths| ≤ 1 + |seed declarations| + |endorsements|.

Proof. The endorsed set in Expand is defined such that a child path is created for (a, k) only when no primary path to (a, k) exists yet. A path becomes primary only when Expand processes it, and SelectFrontier picks at most one path per endpoint per depth under the ¬p.primary filter; once any path to (a, k) becomes primary, the endorsed filter blocks every further addition to (a, k). Hence each binding admits at most one primary path. Each non-root path is created as chain(p) · (a, k) for a (then-primary) parent p and edge (end(p), (a, k)) ∈ N; since each endpoint admits at most one primary path, p is uniquely determined by end(p), so each path corresponds to at most one element in N. Edges in N are either root edges ($, (a, k)), one per binding in the seed declaration collection, or trust edges ((a, k), (a', k')), one per endorsement signed by (a, k) that references a declaration of (a', k'). The number of root edges is therefore at most the number of seed declarations and each endorsement contributes at most one trust edge, so |N| ≤ |seed declarations| + |endorsements| and |paths| ≤ 1 + |seed declarations| + |endorsements|. ∎

Lemma 3 (Determinism). Two Registries running IDEBT with the same setting over the same nanopublications produce identical paths sets, and hence identical per-key trust scores and identical trust-state hashes.

Proof. The initial state (paths, declarations, N) is a function of setting alone. Each iteration applies two operations. (i) Expand adds, for each (a, k) ∈ endorsed, a child whose ratio is fixed by the set cardinalities nagents and nkeys; the resulting paths set is therefore invariant under iteration order. (ii) SelectFrontier's argmax is unique under the lexicographic tie-break introduced after Expand above, since sorthash is unique per path. Both operations are deterministic in (setting, peers), and so is the final paths set. ∎

Nanopub Registry currently instantiates IDEBT with MAX_DEPTH = 10, MIN_RATIO = 10−10, and SELF_SHARE = 0.1; we call this version IDEBT10.

Once IDEBT has terminated and paths is populated, the per-key scores and the trust-state hash can be derived:

for each pubkey k:
  P_k       ← { p ∈ paths : pubkey(end(p)) = k }
  ratio(k)  ← Σ { p.ratio : p ∈ P_k }
  quota(k)  ← clamp(GLOBAL_QUOTA × ratio(k), MIN_QUOTA, MAX_QUOTA)
  A_k       ← { a : ∃ p ∈ P_k, end(p) = (a, k) }
  status(k) ← approved  if |A_k| = 1
              contested otherwise

trustStateId ← hash(canonicalSerialisation(paths))

All trust paths ending at a given public key k are summed into a single ratio in [0,1], mapped to an integer publication quota clamped between MIN_QUOTA and MAX_QUOTA so that every trusted agent gets a minimal quota and nobody gets an excessive one. Keys declared by exactly one agent are marked approved; those claimed by two or more are marked contested and can be resolved socially through further endorsements, as the Knowledge Space whitepaper [10] sketches. Finally, the full path set is canonicalised and hashed (currently SHA-256) into trustStateHash, which downstream services can use to mirror a consistent view.

We first report here from a descriptive analysis of a snapshot of the deployed trust network as observed at the public Registry instance registry.knowledgepixels.com on 2026-05-04, with trust-state hash 4d07f8db…, via its public API. At the time of the snapshot, the registry held 79,672 stored nanopublications signed by 616 distinct agents covering 692 loaded agent-key accounts.

Figure 2 gives three views of the deployed trust graph. The ratio gate alone keeps every path within five hops of the seed, without ever invoking the MAX_DEPTH parameter: the 14 first-hop paths line up cleanly with the seed agent-keys declared in the setting. Panel (b) shows ratio mass decaying geometrically with depth as Lemma 1 predicts, leaving more than three quarters of the 1.0 conservation budget unused. The path set stays linear in the size of the trust graph rather than combinatorial: the 772 paths split into 695 primary chains and 77 deduplicated extensions, and 94.8% of reached accounts sit at the end of exactly one path.

Trust mass and publication volume are concentrated very differently. The top agent carries less than 1% of total trust mass, but a single bot agent (fip-wizard.ds-wizard.org/wizard) signs 30,089 of the 73,603 nanopublications attributable to loaded keys (≈41%), and the top ten agents together account for roughly 87%. Panel (c) sharpens the temporal picture: the 683 first-time agent-key declarations have been accumulating steadily since early 2019, but the explicit trust layer is more recent. The 736 approved endorsements appear from late 2022 onward, and most of the current trust graph was issued in the last two years by 44 active endorsing keys.

To complement the snapshot analysis, we ran a controlled multi-node deployment to measure how the architecture behaves under sustained ingestion and querying as the stored corpus grows. The benchmark runs four Registry instances (each paired with MongoDB) and four Query instances (each paired with RDF4J) on a five-node Kubernetes cluster (one control-plane node and four worker nodes), with each Query instance configured to source from a single Registry. Each worker node is a co-located VM with 12 vCores and 24 GiB RAM, with the RDF4J and MongoDB containers each capped at 8 GiB RAM; all four worker nodes run on a single hypervisor (AMD Ryzen Threadripper 7960X, 256 GiB DDR5, NVMe storage in a ZFS pool) under Ubuntu Server 24.04. Workload generators run on three external Raspberry Pi 5 nodes connected over 1 GbE. A workload generator simulates 50 publishing clients across nine parallel processes, drawing authorship from a Pareto distribution and producing four nanopublication types in proportions 0.60 plain assertion, 0.30 comment, 0.05 update, and 0.05 retraction. The benchmark proceeds in phases of 100,000-nanopublication ingestion followed by a 20-minute query workload of 24 concurrent clients issuing three SPARQL queries (weighted 3:1:2): a registry-wide nanopublication count, a global triple count, and a per-type aggregation.

We compare two Registry coverage configurations. In round-robin replication, all four Registries declare full type coverage and an HTTP scheduler distributes incoming submissions among them; every Registry then holds the full corpus through replication. In type-sharded coverage, each Registry covers a fixed 50-of-100 window of publication types (with 25-type overlap between neighbours) so the average type lives on two Registries; retraction and comment nanopublications are still replicated globally. Each configuration runs for four phases, exposing the system to a corpus that grows from 100,000 to 400,000 stored nanopublications (≈13M RDF triples at the 400k scale).

Type-sharding also lifts read throughput and roughly halves mean response time, with no failed or timed-out queries in either run. Across the 20-minute workload of 24 concurrent clients, the type-sharded cluster serves about 6,900 queries/s on average at ≈2.3 ms mean response time, against ≈5,150 queries/s at ≈4.0 ms under round-robin. As the corpus grows fourfold, the type-sharded numbers stay essentially flat, as seen in the bottom part of panel (a), while round-robin's throughput and latency become visibly more variable. The mechanism mirrors the ingestion side: each type-sharded Query indexes only the types its paired Registry covers, while every round-robin Query carries the full corpus, so RDF4J indexing pressure scales with total content rather than with the locally-relevant subset. In network terms, two operators each covering half the type space serve more queries faster than two operators each replicating everything.

Resource utilisation reflects this division of labour (panels b, c). MongoDB dominates Registry CPU under either configuration, with per-Registry RAM moderately lighter under type-sharding. On the Query side, type-sharding's saving lands on RDF4J CPU, which drops by roughly a third; RDF4J's working set, driven by total content rather than type partition, stays similar across configurations.

Add for final version.