Skip to content

Concept

INRI - Independent Notification Relay Infrastructure

Conceptual Overview

INRI is a federated, privacy-conscious push message relay system designed to replace proprietary and centralized push notification services (e.g., Firebase) that pose issues under data protection regulations like GDPR. The goal is to enable decentralized, secure, and privacy-respecting notification delivery for open-source and self-hosted applications.

Key Objectives

  • Federated Architecture: Every consumer of the network also hosts a node.
  • Privacy-Centric: Avoid persistent personal identifiers in routing.
  • Resilient Delivery: Use tokenized messages to signal clients to fetch updates.
  • Low Bandwidth: Relays only send minimal payloads (e.g., "new message"), not the full data.
  • Device Proximity: Messages should be routed from geographically close nodes.

Minimal Proof of Concept (PoC)

Architecture

  +----------------+       +------------------+      +--------------------+
  | Client Device  | <---> | Relay Node (API) | <--> | RabbitMQ (Queue)   |
  +----------------+       +------------------+      +--------------------+
                                 |
                                 v
                      [Token Table / Store]

Components

Component Technology
API Server FastAPI (Python)
Message Bus RabbitMQ
Token Store In-Memory Dict

Core Endpoints

POST /register

Register a device and receive a set of tokens.

Request: { "client_id": "device-abc", "count": 10 }
Response: { "tokens": ["token-123", "token-456", ...] }

POST /push

Push a message using a one-time-use token.

Request: {
  "token": "token-123",
  "payload": {
    "app": "calendar",
    "message": "new-event"
  }
}
  • Validates token
  • Marks token as used
  • Publishes message to push.device-abc queue

GET /pull/{client_id}

Client pulls available messages from their queue.

Token Lifecycle

  • One-time tokens are pre-generated and handed out.
  • Used tokens are marked and archived.
  • New tokens can be requested periodically.

RabbitMQ Usage

  • Each client has a dedicated queue: push.{client_id}
  • Messages are lightweight and just indicate data presence

Relay Network Architecture

Structure

  • Relays are connected in a loosely meshed topology.
  • Each relay connects to 3–4 neighboring relays.
  • Network routing does not rely on full path knowledge but supports path optimization via cached vectors.

Message Types

  • Gossip messages: Used to discover devices and establish rough routing paths.
  • Push messages: Target specific tokens and follow pre-established paths or fall back to gossip.

Token-Based Path Stabilization

Concept

Each device receives a batch of opaque tokens upon registration. These tokens are used to:

  • Identify the device across multiple relay interactions.
  • Establish or reinforce directional paths through the network.

Phases

1. Registration

  • Device registers with its "home" application server.
  • Server issues a set of unlinked tokens to the device.

2. Propagation

  • When a token is first seen in the network, the route it takes is cached at each relay.
  • Caches store lightweight vectors to reach that token's most recent location.
  • Routes expire after a time-to-live (TTL).

3. Notification

  • When an app wants to push to a device, it sends the message via a token.
  • If the route to the token exists, the message follows the known vector.
  • If not, soft gossip is used as a fallback mechanism.

Routing Behavior

  • Messages are tagged with a TTL.
  • Each relay remembers the origin vector for incoming messages to avoid loops.
  • Relays do not store full paths or user metadata.

Loop Avoidance and Optimization

  • Relays discard messages received from nodes they just sent to.
  • Established paths allow directional shortcuts, reducing gossip overhead.

Security and Privacy

  • Tokens are opaque and non-reversible.
  • Relay routing is based on tokens, not device identifiers.
  • No persistent user data is stored on relays

Self-Healing & Monitoring

  • The system assumes zero trust between relays, relying on federation trust models only as an enhancement.
  • Lost or undelivered push notifications are detected indirectly by the home application when expected client API calls fail to arrive.
  • Since actual content is not transmitted via pushes, occasional lost notifications are tolerable, but repeated failures trigger alerts.
  • Clients can re-register periodically, which causes a fresh set of tokens to be gossiped through the network, effectively healing broken or outdated routing paths.
  • This token refresh mechanism helps maintain network resilience without requiring full path knowledge or centralized coordination.
  • Additional monitoring and flagging systems can be implemented to detect persistent delivery issues and initiate corrective actions.

Messsage propagation

Client registers with Relay 1, initiating the registration propagation. The registration tokens spread via gossip through the network. Relay 1 forwards tokens to Relays 2 and 3, both of which propagate the registration to Relay 4.

Relay 4 receives the token from Relay 2 first, establishing a preferred origin path for later message delivery.

The Home App listens for registration tokens on Relay 6. When it needs to notify the Client, it sends a message to Relay 6, which remembers the token’s origin as Relay 5, which in turn traces it back through Relay 4 → Relay 2 → Relay 1.

Thus, the primary push route follows the fastest registration path discovered during gossip. The final hop delivers the message to Relay 1, where the Client is listening for push notifications.

flowchart TD
    Client["Client (Registration)"]
    R1["Relay 1"]
    R2["Relay 2"]
    R3["Relay 3"]
    R4["Relay 4"]
    R5["Relay 5"]
    R6["Relay 6"]
    App["Home App (Push Origin)"]

    %% Registration Gossip Flow
    Client --> R1
    R1 --> R2
    R1 --> R3
    R2 --> R4
    R3 --> R4
    R4 --> R5
    R5 --> R6
    R6 --> App

    %% Push Notification Path (highlighted separately)
    App ==> R6
    R6 ==> R5
    R5 ==> R4
    R4 ==> R2
    R2 ==> R1
    R1 ==> Client
 %% Styling for clarity
    style Client fill:#c6f6d5,stroke:#2f855a,stroke-width:2px
    style App fill:#bee3f8,stroke:#2b6cb0,stroke-width:2px
    style R1 fill:#f7fafc
    style R2 fill:#f7fafc
    style R3 fill:#f7fafc
    style R4 fill:#f7fafc
    style R5 fill:#f7fafc
    style R6 fill:#f7fafc

    %% Push route labels
    linkStyle 8,9,10,11,12 stroke:#3182ce,stroke-width:2px

Bootstrap Nodes (Antediluvians)

  • Role: Antediluvians are pre-configured, stable relay nodes that serve as initial contact points for new or restarting relays joining the network.
  • Function: Upon startup, a relay contacts one or more antediluvian nodes to discover geographically proximate peers.
  • Discovery: Antediluvians maintain a curated list of known relays with associated metadata (e.g., IP ranges, geographic hints).
  • Routing Assistance: Based on the new relay’s IP address or network location, antediluvians suggest optimal neighboring relays to connect with.
  • Network Stability: By anchoring the network, antediluvians enable bootstrap without requiring global DNS or centralized registries.
  • Security: Trust is minimal; antediluvians only provide initial peer information and do not control routing or message delivery.

Analogy to Root DNS Servers

Antediluvians function similarly to root DNS servers in the Domain Name System. They provide the initial entry points into the network, helping new nodes discover peers without maintaining complete network state or control. Just as root DNS servers enable domain resolution without holding all DNS data, antediluvians enable relay bootstrap with minimal centralized knowledge.

Future Enhancements

  • Redis or PostgreSQL for token persistence
  • Encrypted payloads and token obfuscation
  • Relay federation and routing protocols
  • DNS-based proximity-based routing
  • Geo-sharding and message prioritization
  • Adaptive TTLs based on network density
  • Token refresh and replay protection mechanisms
  • Rate-limiting and abuse prevention strategies
  • Real-time performance metrics and routing diagnostics

Cultural Easter Egg

The acronym INRI (commonly associated with religious imagery) pairs humorously with the choice of RabbitMQ (symbolically tied to rebirth and renewal), reinforcing the open and federated spirit of the project.

Conclusion

This PoC is intended to demonstrate the feasibility of a simple yet effective decentralized push message system, with an emphasis on data privacy and user autonomy. It serves as a foundation for further expansion and experimentation within the community.