RFC: Architecture for Distributed P2P Mesh Resolution (Proposal based on DOI 10.5281/zenodo.18332235)

[Apriloracle]

Hello GS1 CE Maintainers and Community,

First, congratulations on the recent v3.0 release and the migration to the Python 3.10 architecture.

Our research lab has published a formal preprint detailing an architecture for resolving GS1 product identifiers across a distributed peer-to-peer (P2P) mesh. We are opening this Request for Comments (RFC) to discuss how this distributed routing pattern might safely and natively interface with the new v3.0 Python CE resolver.

---

1. The Context

Currently, the standard CE resolver relies heavily on local database ingestion (e.g., MongoDB). While this architecture is excellent for single-tenant or internal enterprise use, it inherently creates a "cold start" problem for newly deployed resolvers. Furthermore, it limits the resolver's ability to dynamically route to—and cryptographically verify—product data originating from external, distributed networks (such as open community databases like Open Food Facts or manufacturer-signed P2P nodes).

---

2. The Proposed Architecture

In our published preprint—"Decentralized Multi-Chain Infrastructure for GS1 Product Identifier Resolution" (DOI: https://doi.org/10.5281/zenodo.18332235) — we outline an architecture for a verifiably distributed routing mesh utilizing append-only logs (Hypercore) and P2P discovery (Hyperswarm).

Rather than proposing a structural rewrite, we are proposing a standard, non-breaking integration hook tailored for the v3.0 Python codebase.

---

3. The Feature Request (EXTERNAL_RESOLVER_URL fallback)

We propose discussing the addition of a standard, optional environment variable/hook (EXTERNAL_RESOLVER_URL) within the v3.0 Python web service routing logic.

How it works:
When a client queries the CE for a GTIN that is not currently stocked in the local MongoDB, the Python routing layer intercepts the standard 404 Not Found response. It then optionally queries the defined EXTERNAL_RESOLVER_URL (acting as a gateway to the distributed mesh) to retrieve the standard Digital Link JSON-LD linkset.

Why it matters:
This allows the CE to act as a seamless hybrid system. Enterprise users maintain strict GS1 compliance, local caching, and total control over their primary data, while instantly gaining access to global, community-sourced and manufacturer-signed product data via a standards-compliant fallback endpoint.

---

4. Next Steps & Reference Implementation

A working Proof-of-Concept (PoC) is available in our fork of the CE repository:
https://github.com/Apriloracle/GS1_DigitalLink_Resolver_CE

The modifications consist of exactly two files:

• A fallback block in web_logic.py (triggered strictly on a local 404 database miss)
• An optional, commented-out EXTERNAL_RESOLVER_URL environment variable in docker-compose.yml

Note: The current PoC code includes a minor DNS translation shim for local Docker Desktop testing, which we will remove for the formal production PR.

Both changes are non-breaking and strictly opt-in by default.

Before submitting a formal Pull Request, we wanted to open this RFC to gather feedback from the maintainers and community on two specific points:

1. Whether this architectural approach is compatible with GS1 CE's compliance goals.
2. The appropriate placement for this hook within the v3.0 Python routing layer.

We are committed to ensuring any implementation maintains strict GS1 Digital Link URI syntax compliance throughout.

---

[nicklansley]

Hello @Apriloracle, and thank you for this well-structured and thoughtful RFC.

To summarise the key points of your proposal to confirm it has been understood:

• You identify a "cold start" limitation in the current CE architecture, whereby a freshly deployed resolver has no local data and therefore cannot resolve any identifiers until its MongoDB is populated.
• You propose an optional EXTERNAL_RESOLVER_URL fallback hook within the v3.0 Python routing layer: when a local 404 database miss occurs, the resolver would transparently query an external endpoint - acting as a gateway to a distributed P2P mesh (built on Hypercore/Hyperswarm) - to retrieve a standards-compliant Digital Link JSON-LD linkset.
• The integration is designed to be strictly opt-in, non-breaking, and limited to two file changes (web_logic.py and docker-compose.yml), with a working PoC already available in your fork.
• The architecture is grounded in a formal preprint (DOI: https://doi.org/10.5281/zenodo.18332235) and aims to enable access to community-sourced and manufacturer-signed product data while maintaining full GS1 Digital Link URI compliance.

This is a genuinely interesting piece of research, and the care taken to keep the integration non-breaking and opt-in is appreciated.

However, it is important to clarify the intended scope of GS1 Digital Link Resolver CE. The CE (Community Edition) is designed as a quick-start resolver for brands and organisations wishing to resolve their own products and GS1 identifiers which is deployed under a domain they own and control (for example, id.brand-domain.com), linked to their own product data and backend systems. It is not intended to act as a general-purpose host or routing hub for GS1 identifiers belonging to third parties, nor as a gateway to external distributed networks.

The distributed P2P mesh resolution pattern you describe, while genuinely innovative, goes beyond this scope and touches on broader questions of GS1 architecture, interoperability policy, and standards governance that are beyond what us CE maintainers can address here, as well as radically altering the scope and lessening the simplicity of Resolver CE.

For that reason, we would encourage you to take this proposal to the GS1 Standards Maintenance Group for Web Technology, which is the appropriate body to evaluate and potentially progress architecturally significant proposals such as this. You can find their details and contact information here:

👉 https://www.gs1.org/standards/development-work-groups

As this discussion falls outside the scope of the Resolver CE project, this discussion will now be closed. We hope you'll pursue this with the Standards Maintenance Group — it deserves a proper hearing in the right forum.

Thank you again for the effort put into this RFC, and best of luck with the proposal!

Best regards
@nicklansley on behalf of the GS1 Digital Link Resolver CE Maintainers

[Apriloracle]

Thank you, we will pursue with the Standards Maintenance Group.