{"id":"efe03f49-a986-49c0-92f7-8ecf0797d257","arxiv_id":"2507.14682","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"IDSS uses a DHT-based P2P overlay over embedded SQLite databases to broadcast, execute, and merge SQL queries, including aggregate functions and limited nested queries, across all peers.","lead":"This paper describes IDSS, a peer-to-peer service that stores relational data in embedded SQLite databases on each node and runs SQL queries across the entire network. It combines a one-hop distributed hash table with broadcast and merge logic, aiming to remove central servers from database storage.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Unvalidated TTL merge heuristic (Eq. 1, newTTL = 3/4 × oldTTL) can silently discard intermediate results in the merge tree, so the claim of executing queries across all peers lacks a demonstrated correctness guarantee; no evaluation or bound is provided.","rationale":"The reader's weakest assumption identifies the same load-bearing concern I find: the TTL merge heuristic in Eq. 1 is the only mechanism bounding the merge process, and the paper provides no experimental or analytical validation that it allows complete result collection. The paper itself labels the process best-effort and admits that low TTL values cause silent discarding of intermediate results (Sec. 3.2.3). This matters because the abstract and the strongest claim assert query execution across all peers with no central server; if the TTL is too low, the returned result is incomplete while the system does not report an error. The heuristic is also fragile: since TTL decreases by a factor of 3/4 at each hop, a parent's merge window is only one quarter of its own TTL, and even modest network latencies can exceed this window at sufficient depth. No quantitative evaluation is reported despite the text stating that overlay sizes from 8 to 1024 peers were tested. The open-source availability is a point in favor, and the architecture is coherent, but the completeness guarantee is not established. Therefore the CONDITIONAL verdict is appropriate: the paper should be accepted only after an experimental study of the TTL heuristic and a correctness argument for query completeness, or an explicit limitation stating that results may be incomplete.","tokens_in":21794,"tokens_out":16297,"duration_ms":190322,"concrete_test":"Deploy IDSS on a containerized cluster of 64 peers with known one-way latency ℓ (e.g., 50 ms and 200 ms), place one distinct row per peer, and submit SELECT COUNT(*) FROM t while sweeping initial TTL from 1 s to 60 s. Compare returned counts to 64 and check whether the minimum TTL for a complete result satisfies 2ℓ ≤ T·(3/4)^i for every depth i in the actual D1HT broadcast tree. If any run returns fewer than 64 without a FAILED state, Eq. 1's 3/4 decrement is not a sufficient bound and the claim of complete query execution across all peers fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central query-processing claim requires that every node's partial results reach the initiator after being merged along the broadcast tree. Section 3.2.3 implements this by giving each node a local TTL, decremented at each hop by Eq. 1 (newTTL = 3/4 × oldTTL), and instructing the node to merge only results received before its TTL expires. The choice of 3/4 is explicitly a heuristic ('we believe provides enough time'), and the paper concedes that low TTL values cause intermediate results to be silently discarded. No bound, measurement, or evaluation for this factor is reported. Concretely, a node at depth i in the broadcast tree must receive and merge child results within T·(3/4)^i of query arrival, while a child at depth i+1 has only T·(3/4)^(i+1) to compute and needs two one-way latencies to return data; results are lost when 2ℓ > T·(3/4)^i − T·(3/4)^(i+1) = T·(3/4)^i/4. Since T shrinks geometrically with depth, any fixed T fails beyond a threshold depth. Thus the 'across all peers' completeness claim is contingent on an unvalidated heuristic, and the system can return incomplete answers while appearing successful.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper presents IDSS, a decentralized relational data storage service that combines the D1HT one-hop distributed hash table with SQLite embedded databases. Users submit SQL queries (with a user-specified TTL) to any peer; the query is broadcast through the DHT, executed locally on all peers, and the partial results are merged along the broadcast tree toward the initiator. The paper contributes the architecture and query-processing design, including aggregate rewriting for AVG via SUM and COUNT, a state machine for asynchronous query handling, and an open-source prototype. The central claim is that IDSS provides a large-scale, fully decentralized P2P relational storage system supporting complex distributed queries without a central server.","tokens_in":22084,"tokens_out":6154,"duration_ms":72511,"significance":"If the architecture were validated, the main value would be the demonstration that a standard embedded relational engine behind a one-hop DHT can support distributed SQL queries, including aggregates and limited nested queries, with no central coordinator. The open-source prototype and the explicit treatment of aggregate merging are positive features. However, the paper currently provides no quantitative evaluation, and its completeness guarantee rests on an unvalidated TTL heuristic, so the significance as a systems paper is not yet established. The contribution relative to prior P2P database work (PeerDB, PORDaS, XPeer) is largely incremental: the specific combination of D1HT, SQLite, and a tree-based merge protocol is new, but no comparison is made to these systems.","major_comments":[{"comment":"The TTL decay rule newTTL = oldTTL × 3/4 is introduced as a heuristic ('we believe provides enough time'), and the text immediately concedes that low TTL values cause intermediate results to be silently discarded. No bound or measurement justifies the factor 3/4. Concretely, even under optimistic assumptions, the merge window for a node at depth i is T·(3/4)^i − T·(3/4)^(i+1) = T·(3/4)^i/4, while a child at depth i+1 needs at least one round trip of two one-way latencies to return its result; hence for any fixed T there exists a depth beyond which child results cannot arrive within the window. This undermines the central claim that queries are executed 'across all peers' (Abstract). The paper should either provide a TTL selection rule that accounts for tree depth and network latency, or explicitly design the system to detect and report incompleteness (e.g., an INCOMPLETE state in Figure 4) instead of treating the merge as normally COMPLETED.","section":"§3.2.3, Eq. (1)"},{"comment":"The only performance evidence is the sentence 'The results show that IDSS exhibits a small memory footprint and is reactive even under high loads (considering the stress test conditions).' No protocol, no measurements, no error bars, and no comparison to any baseline. Since the paper claims 'large-scale' and 'efficient' data management, this omission is load-bearing. The authors mention testing overlay sizes from 8 to 1024 peers; these experiments should be reported with concrete metrics (query latency, memory footprint, merge completeness, TTL sensitivity) and sufficient detail to reproduce them.","section":"§3.3"},{"comment":"The description of nested query execution (Figure 6) is too high-level to establish correctness. The paper states that the initiator obtains a recordset 'broader than that produced by the initial query' and 'all the information needed to retrieve the final recordset,' but it does not prove that fetching the parent query without its WHERE clause, combined with the global aggregate from the subquery, yields exactly the nested-query answer when data are partitioned across peers. There is also no treatment of duplicate elimination if the broadcast tree delivers multiple copies of the same tuple. This point needs either a correctness proof or a complete worked example with schema and data.","section":"§3.2.6"}],"minor_comments":[{"comment":"The UQI acronym is defined as 'Universal Query Identifier' in Section 3.1 but as 'Uniform Query Identifier' in Table 1; pick one definition and use it consistently.","section":"§3.1 vs Table 1"},{"comment":"The reference list contains several LaTeX artifacts and incomplete metadata, e.g., 'Nambiar and Mundra (2022,?)' and the 'Bod´ o' author name; a copyediting pass is needed.","section":"References"},{"comment":"The broadcast and duplicate-discard scenario is described in the body text, but the figure does not label nodes aa1, cc3, and dd4 or indicate the first-arrival order, which makes the example hard to follow.","section":"Figure 2"},{"comment":"The statement that 'the TTL value should be directly proportional to the number of records expected to be retrieved (linear relationship)' is presented without justification; this is an assumption and should be stated as such or supported by an argument.","section":"§3.2.3"}],"recommendation":"major_revision","confidential_remarks":"This manuscript is more of an architecture and position paper than a typical systems evaluation. The absence of any measurement is unusual for a cs.DB paper claiming 'large-scale' and 'efficient' behavior; the editor may wish to require an experimental section with reproducibility data before acceptance. I also note that the authors cite their own earlier work (Sundsgaard et al. 2024) for the decentralized relational data model, but the current architecture does not depend on that work, so there is no circularity concern."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things to know up front. First, this is a real design-and-implementation paper: the architecture is coherent, the code is on GitHub, and the authors are candid about their own limits. Second, it contains essentially no evaluation. Section 3.3 reports that the system 'exhibits a small memory footprint and is reactive even under high loads,' and that one sentence is the entire empirical content.\n\nWhat is genuinely new is the combination: a one-hop DHT (D1HT) as the overlay, an embedded SQLite database at every peer, a common relational schema, a Universal Query Identifier for duplicate suppression during broadcast, and a tree-based broadcast-and-merge execution model. That combination is not in the cited literature, and the novelty claim holds. The merge strategy — each node merges child results into its own and sends upward — is a real answer to the initiator-bottleneck problem, and the query state machine is clean. The average handling deserves credit: replace avg with sum and count at every local execution, recombine at the initiator. Nested query support is genuinely restricted (two levels, no correlation, same-kind subqueries), but the restrictions are stated plainly.\n\nThe main soft spot is the missing evaluation, and it is load-bearing because the system's promise is that queries execute across the overlay. The TTL merge heuristic (Eq. 1, newTTL = 3/4 × oldTTL) is the related weak point. The stress-test arithmetic is right: TTL shrinks geometrically with tree depth, so any fixed T cannot cover the whole network past some depth, and results get dropped silently. But the paper already concedes that — the merge is declared best-effort and low TTL is acknowledged to discard intermediate results. So this is not a hidden flaw; it is an uncharacterized one. Nothing in the paper tells the user how TTL should scale with network size and latency, and no experiment bounds the 3/4 factor even for the tested 8–1024 peer range. An evaluation gap, not a refutation.\n\nRelated work is thorough for grid information services from 2003–2010; the modern P2P database comparison (OrbitDB, Peerbit, GUN, DefraDB) is brief but fair. The self-citation to the authors' earlier decentralized data model is appropriate since the design builds on it directly, and there is no parameter fitting anywhere, so the circularity burden is genuinely low.\n\nThe right reader wants a worked, checkable prototype of a common-schema P2P relational store, or a case study in what evidence a P2P database paper should carry. I would bring it to a reading group and would likely cite it in work on P2P query processing.\n\nRecommendation: yes, send it to peer review. The novelty is defensible, the code is checkable, and the honest limits make it a strong revise-and-resubmit candidate. The referee should demand actual measurements — the VM setup with 8–1024 peers is described, so the authors probably have data they did not report — plus a completeness characterization of the TTL merge and clearer experimental conditions.","headline":"A coherent, genuinely new P2P relational design with open-source code and honestly stated limits — but the entire empirical evaluation is one sentence and the TTL merge heuristic is uncharacterized.","tokens_in":22604,"tokens_out":6508,"would_cite":true,"duration_ms":70906,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"IDSS claims a peer-to-peer overlay can run distributed SQL queries across every peer with no central server.","keywords":["peer-to-peer storage","distributed query processing","distributed hash table","embedded relational database","SQL aggregation","nested queries","decentralised database","best-effort query merge"],"falsifier":"Deploy IDSS on a network with known per-peer row counts and submit a count(*) query with a TTL smaller than the measured time needed for the farthest peer's result to travel back; if the returned count is below the ground-truth total and the query is reported as successful, the best-effort merge is silently losing data.","tokens_in":21622,"feed_emoji":"🗄️","tokens_out":7330,"duration_ms":82831,"temperature":0.7,"pith_summary":"IDSS is a proposed storage service that combines a peer-to-peer overlay with an embedded relational database on every peer, so data can be spread across many machines with no central server. The paper's central claim is that a SQL query submitted to any peer can be broadcast through the overlay, executed locally on every peer, and merged along the reverse path back to the submitter, yielding the same relational results a single database would produce. It argues that this design supports selective queries, aggregate functions, and two-level nested queries while remaining responsive at overlay sizes from 8 to 1,024 peers. A sympathetic reader would care because this is a concrete architectural route to scalable, fault-tolerant SQL storage that avoids the scaling and single-point-of-failure problems of centralised databases.","feed_headline":"One SQL query, 1,024 peers, zero central servers","feed_subtitle":"IDSS broadcasts each query through a peer-to-peer overlay and merges partial answers hop by hop, even for aggregates and nested queries.","key_machinery":"The load-bearing mechanism is the per-query state kept in every peer's QUERY table, which turns a broadcast tree into a merge tree. Each row stores the query's UQI (to recognise and discard duplicates), the sender_key (to route merged results back along the path), flags for local execution, merge completion, and failures, and a TTL computed as newTTL = oldTTL × 3/4 at each hop (Equation 1). The node waits until its TTL expires, merges the partial recordsets it has received with its own local result, and sends the combined recordset to the sender_key. For aggregate queries the same table supports a rewrite rule: replace each AVG expression with SUM and COUNT before local execution, then reconstruct the average at the initiator, which works because sum, count, min, and max are mergeable across partitions while arithmetic mean is not.","core_discovery":"The paper sets out to prove that a fully decentralised relational data storage service is feasible: each peer runs an embedded SQL engine behind a structured one-hop DHT overlay, and every peer that receives a query executes it against a shared schema and returns partial results. Queries carry a Universal Query Identifier (UQI) so duplicate broadcasts are discarded, a sender key so each peer knows where to send merged results, and a time-to-live (TTL) that shrinks by a factor of 3/4 at each hop; each peer waits up to its TTL for children's results, merges them with its own local recordset, and forwards upstream. For aggregate queries, the paper shows that sum, count, min, and max can be merged directly, while average is handled by rewriting AVG(x) locally as SUM(x) and COUNT(x) and dividing at the initiator. Nested queries are supported up to two levels when subqueries are not correlated and are all of the same kind; the paper reports a prototype with 8 to 1,024 peers that showed a small memory footprint and remained reactive under load.","pith_inferences":["The AVG rewrite extends naturally to other aggregates expressible from sum and count, such as variance and standard deviation, though the paper does not claim this.","Because completeness depends on TTL, a production deployment would need a side-channel to tell users whether the returned answer is partial; the paper leaves that detection implicit.","A one-hop overlay means broadcast reaches every peer in a fixed number of routing steps, so the main scalability question shifts from lookup cost to the cost of merging N partial resultsets at the initiator.","The design assumes one shared schema; adding schema translation between peers would be a natural next step and is not addressed in the paper."],"forward_implications":["A user can submit a SQL query to any peer and later collect the complete relational answer from it, without any node acting as a database server for the whole network.","Aggregate queries over all peers return the correct global sum, count, minimum, and maximum, and averages are recovered from rewritten sum/count pairs.","Nested queries with one level of subqueries, including aggregate subqueries, can be partitioned into elementary clauses and reassembled at the initiator.","The TTL value becomes an explicit accuracy/latency dial: higher TTLs give more complete results, lower TTLs answer faster but silently drop partial results.","The prototype's measured behaviour on 8 to 1,024 peers indicates the approach can keep a small memory footprint and stay responsive under load."],"supporting_citations":[{"why":"Supplies the one-hop DHT overlay used for broadcast and key-based routing.","marker":"Monnerat and Amorim (2015)"},{"why":"Supplies the embedded SQL engine used at each peer for local storage and query execution.","marker":"Gaffney et al. (2022)"},{"why":"Supplies the uniform data-access layer and bulk query library used inside IDSS.","marker":"Aloisio, Cafaro, Fiore, and Mirto (2004)"},{"why":"Supplies the SOAP/XML toolkit used to implement the service and its clients.","marker":"Engelen (2008)"},{"why":"Supplies the reference architecture for P2P data management that the design adopts.","marker":"Özsu and Valduriez (2020)"},{"why":"Identifies the open problems in P2P data integration that IDSS aims to address.","marker":"Calvanese, De Giacomo, Lembo, Lenzerini, and Rosati (2006)"}],"fun_headline_variants":["P2P relational storage runs SQL over 1,024 peers","No central server: IDSS broadcasts queries across peers","Aggregates and nested SQL queries in a decentralized grid","Embedded SQL engines on a DHT make scalable P2P storage","IDSS merges partial query results hop-by-hop in P2P"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The entire merge procedure rests on the heuristic that a time-to-live reduced to three-quarters of its value at each hop gives nodes enough time to receive and merge all partial results; if that guess is wrong for the network's size or latency, queries return incomplete answers while still appearing to have succeeded.","fun_headline_variants_meta":{"raw":{"variants":["P2P relational storage runs SQL over 1,024 peers","No central server: IDSS broadcasts queries across peers","Aggregates and nested SQL queries in a decentralized grid","Embedded SQL engines on a DHT make scalable P2P storage","IDSS merges partial query results hop-by-hop in P2P"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000222,"raw_usage":{"total_tokens":1425,"prompt_tokens":885,"completion_tokens":540,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":501,"completion_tokens_details":{"reasoning_tokens":452}},"tokens_in":501,"tokens_out":540,"duration_ms":6609,"temperature":1.0,"reasoning_tokens":452,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T15:50:16.107940+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Deploy IDSS on a network with known per-peer row counts and submit a count(*) query with a TTL smaller than the measured time needed for the farthest peer's result to travel back; if the returned count is below the ground-truth total and the query is reported as successful, the best-effort merge is silently losing data.","supporting_citations":[{"cited_title":"\\ Amorim, C.L","cited_arxiv_id":null,"evidence_quote":"Supplies the one-hop DHT overlay used for broadcast and key-based routing."},{"cited_title":"DeSePtion: Dual Sequence Prediction and Adversarial Examples for Improved Fact-Checking","cited_arxiv_id":"2004.12864","evidence_quote":"Supplies the uniform data-access layer and bulk query library used inside IDSS."},{"cited_title":"APACrefauthors \\ 2008 05","cited_arxiv_id":null,"evidence_quote":"Supplies the SOAP/XML toolkit used to implement the service and its clients."},{"cited_title":", De Giacomo, G","cited_arxiv_id":null,"evidence_quote":"Identifies the open problems in P2P data integration that IDSS aims to address."}],"review_version":1}