Universe Controller
| Search results will appear here |
|---|
Network Map
Live status of the Shopnet ecosystem
Client Portals
Combined product + domain marketplaces
Domain Stores
TLD marketplaces and domain discovery sites
Product Stores
E-commerce stores (Shopify, WooCommerce) with checkout
Brochure Sites (On Demand)
Lambda-hosted endpoints on S3 + CloudFront - generated on request
Brochure Sites (Persistent)
Radius-managed persistent sites with continuous hosting
Web3 Sites
One-page domains with IP certs (emoji TLDs like hello.🌐)
Social Channels WIP
Manage social media integrations and content distribution
Mail Chimp
Email marketing campaigns and subscriber management.
YouTube
Video content management and channel analytics.
Photo and story content scheduling.
Page management and post scheduling.
Files & Data Sources
Data management and administration
Loading databases from RDS...
Site Index
Website records from shopnet_site_index RDS table - domain configs and site_uid assignments
| Site ID ↕ | Domain ↕ | Assigned At ↕ | Assigned By | Status ↕ | S3 Folder |
|---|---|---|---|---|---|
| Loading... | |||||
AI Engines
Agent Engine endpoints (site_uid type A) — applications that host agent platforms
Assist.Shopnet — Agent Overview v1.0 Agent Guide
AI agent architecture, instances, and management
Reference Guide | February 8, 2026 | 8 Agent Instances across 6 Platforms
Registered Agent Instances
Each agent is an instance on a platform (Level 0 endpoint). Agents are identified by agent_uid (SA-XXXXXXXX),
platforms by site_uid (SN-XXXXXXXX). Both are issued exclusively by Connect Gateway.
Agent Architecture
Network Identity Hierarchy
| Level | Identity | Format | Status |
|---|---|---|---|
| L0 | Endpoint (Platform) | SN-XXXXXXXX |
Active |
| L1 | Agent Instance | SA-XXXXXXXX |
Active |
| L1 | Website Instance | SW-XXXXXXXX |
Future |
| L2 | Assignment | TBD | Future |
Data Storage
next_site_uid · next_agent_uid
Agent Instance Management
THE LAW — agent_uid (v4.0)
- Connect Gateway is the ONLY authority for
agent_uidgeneration - Format:
SA-XXXXXXXX(8-digit zero-padded sequential number) agent_uidis NEVER reused, even after deletionagent_uidcounter stored in network-endpoints.jsonmetadata.next_agent_uid- Level 1 wizards (Agent) CANNOT modify Level 0 data (endpoint_taxonomy, site_uid)
POST /api/v1/agent-uid/create — Issues new SA-XXXXXXXXGET /api/v1/agent-uid/next — Preview next agent_uidGET/POST /api/v1/agents — List/Create agent recordsGET/PUT/DELETE /api/v1/agents/{agent_uid} — CRUD operationsGET /api/v1/agent-platforms — List registered agent platforms
Data.Shopnet — DB Overview v1.0 Database Guide
Complete Database Topology of the Shopnet Network
Reference Guide | February 8, 2026 | 8 Databases across 2 RDS Instances + S3
Infrastructure Topology
The Shopnet Network operates 8 PostgreSQL databases across 2 AWS RDS instances plus S3 object storage, all routed through the Connect Gateway API.
RDS Instance 1
shopnet_data — Domain TLDsamazon_products — Product catalogshopnet_sites — Site managementKPI_Source — Analyticsshopnet_connect — UID registryshopnet_assist — Agent managementRDS Instance 2
shopnet_crm — User identityshopnet_registry — Lists & wishlistsS3 Storage
shopnet-domain-images — AssetsDatabase Summary
| Database | Tables | Records | Instance | Purpose | Console Panel |
|---|---|---|---|---|---|
| shopnet_data | 11 | ~7,800 | Instance 1 | Domain TLD management — 2,000+ TLDs, categories, relevancy scores | RDS Domain Database |
| amazon_products | 10 | ~245,600 | Instance 1 | Product catalog — 13k products, 230k reviews for AI agents | RDS Product Database |
| shopnet_sites | 8 | ~451 | Instance 1 | Site management — endpoint taxonomy, builds, DNS, infrastructure | RDS Sites Database |
| KPI_Source | 5 | varies | Instance 1 | Analytics — dashboards, metric templates, cached KPIs | RDS KPI Database |
| shopnet_assist | 9 | 20 | Instance 1 | AI agent management — agents, rules, tasks, invocations | RDS Agent Database |
| shopnet_crm | 7 | 5 | Instance 2 | User identity — profiles, site registrations, delegations | RDS CRM Database |
| shopnet_registry | 3 | 5 | Instance 2 | Lists & wishlists — registries, sharing tokens | RDS Registry Database |
| S3 | — | files | us-east-1 | Domain assets — images, icons, banners, static content | S3 Content Files |
Key Tables Core Data
These tables form the backbone of the Shopnet Network data layer.
endpoint_taxonomy
86 rows · shopnet_sites
The "Golden Table" — master register of every endpoint. 32 columns including site_uid, domain, pulse status, taxonomy codes.
tlds
2,011 rows · shopnet_data
Master TLD inventory. 44 columns with emoji/kanji analysis, pricing, SODI scores, Hall of Fame.
products / reviews
244k rows · amazon_products
Product catalog + reviews. AI-generated pros/cons summaries. Powers product.assist agents.
user_taxonomy
2 rows · shopnet_crm
Master user identity. su_ UIDs with email, auth provider, status. Same UID across all sites.
agents
8 rows · shopnet_assist
Agent fleet registry. 37 columns: personality, system prompts, model tier, escalation chains, permissions.
uid_registry
all UIDs · shopnet_connect
The SND "zone file". Every UID ever issued with type, version, routing, and issuance audit trail.
Cross-Database Relationships SND UIDs
Databases are connected through SND UIDs — the universal identifier system. Each UID prefix routes to a specific database.
↓ ↓
sa_ agents (shopnet_assist) user_site_registrations
↓ ↓
user_delegations.agent_uid sl_ list_taxonomy (shopnet_registry)
↓
list_items.external_ref → products.asin
Connect Gateway API connect.shopnet
All database access is routed through the Connect Gateway at connect.shopnet.network. Total of 98+ API endpoints.
| Database | API Prefix | Endpoints | Key Operations |
|---|---|---|---|
| shopnet_data | /api/v1/tlds/*, /api/v1/categories/* |
10 | TLD CRUD, category management, stats |
| amazon_products | /api/v1/products/* |
2 | Product search, category listing |
| shopnet_sites | /api/v1/sites/*, /api/v1/taxonomy/* |
14 | Site CRUD, build, pulse, taxonomy |
| KPI_Source | /api/v1/kpi/* |
19 | Dashboards, metrics, templates, auth |
| shopnet_assist | /api/v1/agents/*, /api/v1/assist/* |
7 | Agent CRUD, table listing |
| shopnet_crm | /api/v2/crm/* |
9 | User registration, delegations, sites |
| shopnet_registry | /api/v2/registry/* |
9 | Lists, items, sharing tokens |
| shopnet_connect | /api/v2/uid/*, /api/v2/snd/* |
12 | UID create/resolve, SND monitor, secrets |
Connected Services
Each database powers one or more Shopnet services:
Design Principles
RDS Agent Database WIP
Agent records, rules, permissions and invocation history (shopnet_assist)
Agent Database Overview
Database Connection
| Database Name | shopnet_assist |
| Host | shopnet-things.cenq4au2o7vl.us-east-1.rds.amazonaws.com |
| RDS Instance | Instance 1 |
| API Gateway | connect.shopnet.network/api/v1/assist/* |
| Status | Connected |
GET /api/v1/assist/tables— List all agent database tablesGET /api/v1/agents— List agent recordsPOST /api/v1/agents— Create agent recordGET /api/v1/agents/{agent_uid}— Get agent details
Agent Database Tables
| Table Name | Records | Last Updated | Actions |
|---|---|---|---|
|
Click refresh to load tables from shopnet_assist
|
|||
Network Nodes WIP
Third-party integrations, redirect management, and Web3 infrastructure
Third Party APIs
Freename
Web3 domain registry integration.
Amazon
Product catalog and affiliate integration.
Walmart
Walmart product data integration.
Chewy
Pet products data integration.
Redirect Hubs
QR Codes
Dynamic QR code generation and tracking.
NFC Tags
Near-field communication tag management.
Web2 SmartLinks
Traditional smart link routing and analytics.
Web3 Gateway
Blockchain-based redirect and resolution.
Web3 DAAS
Web3 SmartLinks
Decentralized smart link routing.
Domain Pay
Domain-based payment processing.
Gateway Router
Web3 domain routing and resolution.
IPFS Integration
Decentralized content hosting.
Blockchain Registry
On-chain domain registration records.
Web3 Gateways WIP
Web3 domain resolution and gateway routing services
RDS Product Database WIP
Product catalog with 13k products and 230k reviews for product.assist
Product Manager
Manage Products from amazon_products Database
Product Sources
| ID | Title | Brand | Price | Rating | Reviews | Category | SOPI | Actions |
|---|---|---|---|---|---|---|---|---|
| Use the finder above to search for products | ||||||||
RDS Sites Database
Site configuration for Lambda and Radius brochure sites
Sites Overview
| Domain | Hosting | Agent Type | Template | Status | Actions |
|---|---|---|---|---|---|
|
Click "Refresh" to load sites from shopnet_sites database
|
|||||
RDS KPI Database
KPI metrics and performance data (KPI_Source)
KPI Overview
Database Connection
| Database Name | KPI_Source |
| Host | shopnet-things.cenq4au2o7vl.us-east-1.rds.amazonaws.com |
| API Gateway | connect.shopnet.network/api/v1/kpi/* |
| Status | Pending Setup |
GET /api/v1/kpi/tables- List all KPI tablesGET /api/v1/kpi/metrics- Get available metricsGET /api/v1/kpi/data/{table}- Query table dataPOST /api/v1/kpi/query- Custom queries
KPI Tables
| Table Name | Records | Last Updated | Actions |
|---|---|---|---|
|
KPI_Source database connection pending
API endpoints need to be created in connect.shopnet
|
|||
RDS CRM Database WIP
User identity, profiles, site registrations and delegations (shopnet_crm)
CRM Database Overview
Database Connection
| Database Name | shopnet_crm |
| Host | shopnet-crm-registry.cenq4au2o7vl.us-east-1.rds.amazonaws.com |
| RDS Instance | Instance 2 |
| API Gateway | connect.shopnet.network/api/v1/crm/* |
| Status | Connected |
GET /api/v1/crm/tables— List all CRM database tablesGET /api/v1/crm/users— List user recordsGET /api/v1/crm/users/{user_uid}— Get user detailsGET /api/v1/crm/delegations— List user-agent delegations
CRM Database Tables
| Table Name | Records | Last Updated | Actions |
|---|---|---|---|
|
Click refresh to load tables from shopnet_crm
|
|||
RDS Registry Database WIP
Lists, wishlists, registries and sharing tokens (shopnet_registry)
Registry Database Overview
Database Connection
| Database Name | shopnet_registry |
| Host | shopnet-crm-registry.cenq4au2o7vl.us-east-1.rds.amazonaws.com |
| RDS Instance | Instance 2 |
| API Gateway | connect.shopnet.network/api/v1/registry/* |
| Status | Connected |
GET /api/v1/registry/tables— List all registry database tablesGET /api/v1/registry/lists— List all wishlists and registriesGET /api/v1/registry/lists/{list_uid}— Get list detailsGET /api/v1/registry/lists/{list_uid}/items— Get list items
Registry Database Tables
| Table Name | Records | Last Updated | Actions |
|---|---|---|---|
|
Click refresh to load tables from shopnet_registry
|
|||
S3 Content Files
Manage domain assets and content endpoints
Endpoint Overview
| Site ID | Domain | Status | Mode | Schedule | Last Sync | Files | Actions |
|---|---|---|---|---|---|---|---|
|
Loading endpoints...
|
|||||||
Content Browser
| Name | Size | Modified | ||
|---|---|---|---|---|
|
Select a domain to view files |
||||
Radius Site Builder v1.0 Site Builder
Modular workflow engine for building websites on the ShopNet network
Architecture Reference | February 2026 | V1 Active Development
What Is Radius Core
Radius is the ShopNet network's modular workflow engine for building websites. It automates the full site lifecycle:
create, configure, deploy, update, monitor, and delete. It operates on site_uid/W endpoints
— it does NOT create endpoints (V1). Connect Gateway is the ONLY authority for issuing site_uid.
Radius lives inside shopnet.network-console/radius/ and is coded separation-ready for future extraction
to a standalone radius.shopnet repository.
Site Types V1
| Platform | Infrastructure | Status |
|---|---|---|
| SC — S3+CloudFront | S3 static + CloudFront CDN + OAC | V1 Building |
| CP — CloudFront Persistent | EC2/nginx + CloudFront CDN | Needs Completion |
| CO — CloudFront On-Demand | Lambda + API Gateway | LIVE (47 sites) |
| WP — WordPress | PHP/EC2 | V2 Stub |
| SH — Shopify | External/Storefront API | V2 Stub |
Roadmap V1 → V3
Module Architecture Engine
Radius uses a workflow engine that maps (site_type, action) to ordered step lists.
14 pluggable modules are discovered dynamically via core/registry.py (factory pattern).
config_fetcher → site_registry → rds_manager → template_renderer
→ deployer.upload_to_s3 → aws_infra.create_s3_cloudfront_distribution
→ rds_manager.update → status_reporter
Connect Gateway Relationship THE LAW
Connect Gateway is the ONLY authority for issuing site_uid. Radius builds on existing endpoints
— it never creates them (V1). All endpoint creation goes through Connect Gateway wizards on the Endpoint Tools page.
Radius App Store Server Online
Build, manage, and monitor Radius-hosted websites
Site Operations
Radius AI Assistant
The AI Assistant is automatically invoked when workflow steps fail. It provides:
- Error diagnosis and root cause analysis
- Suggested fixes and remediation steps
- Escalation reports for manual intervention
Site Editor v1.0
Visual template editor with live preview — edit branding, content, and deploy to S3+CloudFront
Radius Managed Sites
Manage Radius-hosted persistent sites
| Status | Site UID | Domain | Type | Platform | SSL | Updated | Actions |
|---|---|---|---|---|---|---|---|
| Loading sites... | |||||||
Radius Module Status
Real-time status of Radius workflow modules
Real-time status of Radius workflow modules during site operations.
Execution Log
Github Modules
Reusable templates, modules, MD documents and documentation for shopnet.ai endpoints — github library.shopnet
BROCHURE SITE MODULES
Brochure Site Template
Base template for creating new brochure sites.
Brochure Client Plugin
Lightweight connector for brochure sites to Connect API.
STORE SITE TEMPLATES
WP Domain Affiliate Site
WordPress template for domain affiliate sites.
WP Product Affiliate Site
WordPress template for product affiliate sites.
WPWoo Product Store Site
WooCommerce template for product stores.
Shopify Product Store Site
Shopify template for product stores.
STORE SITE MODULES
connect.shopnet API
Core Connect Gateway API for ShopNet services.
↗Connect Client
Client-side connector for ShopNet sites.
↗Search Plugin
Product and content search functionality.
↗Database Plugin
Database connectivity and data management.
↗KPI Dashboard
Real-time metrics and analytics dashboard.
AI AGENT MODULES
SHOPNET LIBRARY
NETWORK CAPABILITIES
Deathstar Architecture v5.0
Complete ShopNet network architecture. 47 docs, THE LAW v5.0 + THE SND LAW v1.0, 8 databases, 5 UID types.
↗THIS IS THE LAW v6.0
Company data blueprint: site_uid + agent_uid rules, endpoint taxonomy, dynamic validation, SND namespace, 8 Parts + 5 Appendices.
↗Lambda Architecture v1.0
Brochure sites Lambda process blueprints. THE LAW compliant - site_uid via Connect Gateway.
↗Shopnet Universe v1.0
Domain cloud visualization and Universe Controller technical documentation.
↗Radius Architecture v1.0
Site Deployment Engine - module workflows, launch sequences, debugging reference.
THIS IS THE LAW v6.0 SND LAW
SND Namespace Governance — The Constitutional Document of the Shopnet Network
Definitive Master Document | February 11, 2026 | Authority: TJL
The Zeroth Law
"THE LAW exists to be re-written to improve and evolve. It exists so that at any given point in time the Entire System is compliant."
THE LAW is a living governance framework. v6.0 is the definitive master document — 8 Parts covering the entire SND namespace, all five UID types, v2 format, dynamic taxonomy, database topology, and Agent Taxonomy (Platform/Instance).
SND Core Principles
uid_registry and uid_issuance_log — the master index and audit trail
user_uid (su_) has ULTIMATE AUTHORITY — agents serve users, never the reverse (The First Law)
The SND Namespace snd.shopnet
SND = Shopnet Network Deathstar — "DNS Backwards". DNS resolves names to addresses. SND resolves UIDs to entities.
DNS (Internet)
Resolves names to addresses
Has a zone file
Has ICANN as authority
SND (Shopnet)
Resolves UIDs to entities
Has uid_registry as zone file
Has Connect Gateway as authority
The SND namespace is flat, not hierarchical. Every UID exists at the same level. Relationships between entities are expressed through junction tables and foreign keys, never through UID structure.
v2 UID Format LIVE
| Attribute | v1 (Legacy) | v2 (SND) |
|---|---|---|
| Pattern | SX-XXXXXXXX |
xx_xxxxxxxxxxxx |
| Length | 11 characters | 15 characters |
| Body | 8-digit sequential integer | 12 base36 chars (timestamp + random) |
| Capacity | 99,999,999 per prefix | ~4.7 quintillion per prefix |
| Prefixes | 2 (SN, SA) | 5 (sn, sa, su, sl, sp) |
| Sortable | By sequence number | By creation timestamp |
The Five Prefixes — UID Routing
Every entity belongs to exactly one of five types. The 2-character prefix routes to the correct database — no lookup table needed.
| Prefix | Full Name | Entity Type | Target Database | Domain | Status |
|---|---|---|---|---|---|
sn_ |
Shopnet Network | Sites / Endpoints | shopnet_sites |
Network | LIVE |
sa_ |
Shopnet Assist | Agents | shopnet_assist |
Network | LIVE |
su_ |
Shopnet User | Users / Accounts | shopnet_crm |
Identity | Designed |
sl_ |
Shopnet List | Lists / Registries | shopnet_registry |
Content | Designed |
sp_ |
Shopnet Payment | Payments / Transactions | shopnet_payments |
Transactions | Future |
The First Law — User Authority
The Pointer Pattern
Rule: If we did not create the entity, we do not UID the entity. We POINT to it using its natural identifier.
Amazon Products
Referenced by ASIN
(e.g., B08N5WRWNW)
Shopnet Domains
Referenced by domain name
(e.g., foo.shop)
Custom Items
Referenced by user text
(e.g., "Blue shoes size 10")
Lists (sl_) own their UID. Items inside are pointers to external identifiers. No proprietary product_uid or domain_uid — this avoids the trap of indexing third-party databases.
SND Monitor — Validation Layer
The SND Monitor is the compliance engine. It validates every UID against four checks continuously — the immune system of the namespace.
| # | Check | What It Validates | Failure Means |
|---|---|---|---|
| 1 | Uniqueness | No two entities share the same UID | Collision — critical failure |
| 2 | Consistency | Every UID in target DB exists in uid_registry | Orphan UID — issued outside gateway |
| 3 | Immutability | No UID has been modified after issuance | UID tampering — integrity violation |
| 4 | Audit | Every UID has a record in uid_issuance_log | Missing audit trail |
Data Sources: uid_registry + uid_issuance_log (shopnet_connect) validated against all target databases. Flagged UIDs are quarantined for investigation.
Database Topology — 2 RDS Instances
Instance 1: amazon-products-db LIVE
shopnet_data — General platform datashopnet_sites — Endpoints, taxonomy [sn_]shopnet_assist — Agent registry [sa_]amazon_products — Product catalogKPI_Source — Analytics, dashboardsshopnet_connect — Gateway, uid_registry, uid_issuance_logInstance 2: shopnet-crm-registry LIVE
shopnet_crm — Users, profiles, history [su_]shopnet_registry — Lists, wishlists [sl_]shopnet_payments [sp_] — instance TBD
Master Index: uid_registry in shopnet_connect is the zone file of SND. Every UID that exists has a row here. uid_issuance_log is the append-only audit trail.
Governance Hierarchy — 3 Levels
Governance flows downward. Never upward. A lower level cannot violate a higher level. THE LAW can only change per the Zeroth Law.
Level 1: Namespace snd.shopnet
UID format, issuance rules, sole issuer principle, uid_registry, SND Monitor
Authority: THE LAW (v6.0) | Enforced by: Connect Gateway
Level 2: Domains (4)
Domain-specific rules, access patterns, data retention, privacy policies
Level 3: Entity Types
Entity-specific schemas, validation rules, business logic. Most granular — most likely to change — always within Level 2 and Level 1 constraints.
Dynamic Taxonomy Implementation LIVE Feb 7
Single source of truth: taxonomy_definition table (79 rows, 35 platform_types). Adding a new platform type = one INSERT. No code changes needed.
validate_platform_type() reads from taxonomy_definition
/api/brochure/taxonomy-definitions/platform-options
loadPlatformOptions() fetches from API on open
Endpoint Type Classification (Level 1) 6 Active
| Code | Type | Count | Description |
|---|---|---|---|
| W | Website | 53 | Domains that serve web pages to users (brochure, store, portal) |
| A | Agent Engine | 8 | Applications that host agent platforms (Assist Engine, LLM hosting) |
| D | Database | 6 | Data stores (RDS PostgreSQL, DynamoDB, S3, GitHub, third-party) |
| N | Node | 8 | Network nodes: Web3 gateways, API hubs, redirect hubs, LLM services |
| I | Infrastructure | 1 | AWS infra: S3, Lambda, SQS, SNS, EC2, RDS, CloudFront, API Gateway, Lightsail |
| O | Other | 0 | Uncategorized endpoints that don't fit other types |
76 endpoints total on production (53W + 8A + 6D + 8N + 1I + 0O). Legacy code ND (Non-Domain) was split into N/I/O on Feb 4, 2026. Zero ND records remain.
Platform Types (Level 2) — 35 Types LIVE
Source: taxonomy_definition table. Dynamic trigger validates platform_type against endpoint_type.
W Website — 9 platform types
| Code | Name | Description |
|---|---|---|
| CO | CloudFront On-Demand | Lambda-backed, scales to zero |
| CP | CloudFront Persistent | nginx on EC2, always running |
| WP | WordPress | PHP on EC2 with WordPress |
| WW | WooCommerce | WordPress with WooCommerce |
| SH | Shopify | External Shopify store |
| CL | Custom Lambda | Custom Lambda function |
| S3 | S3 Static | Static files on S3 |
| LM | Lightsail | Amazon Lightsail instance |
| L3 | Layer3 Web3 | Lambda@Edge with IP certs for emoji TLDs |
A Agent Engine — 5 platform types
| Code | Name | Description |
|---|---|---|
| CL | Claude Engine | Anthropic Claude-based agent engine |
| GP | GPT Engine | OpenAI GPT-based agent engine |
| GM | Gemini Engine | Google Gemini-based agent engine |
| CA | Custom Engine | Custom agent engine implementation |
| OT | Other Engine | Other agent engine |
D Database — 5 platform types
| Code | Name | Description |
|---|---|---|
| RD | RDS PostgreSQL | Amazon RDS PostgreSQL |
| DY | DynamoDB | Amazon DynamoDB |
| S3 | S3 Data Lake | S3 as data store |
| GIT | GitHub Repository | GitHub code repository |
| TPD | Third Party DB API | External database API |
N Node — 6 platform types
| Code | Name | Description |
|---|---|---|
| W3G | Web3 Gateway | Web3 domain resolution gateway |
| API | API Hub | API service endpoint |
| RDH | Redirect Hub | URL redirect service |
| W3S | Web3 DAAS | Web3 decentralized service |
| LLM | LLM Service | Large language model service |
| OTH | Other Node | Other network node |
I Infrastructure — 9 platform types
| Code | Name | Description |
|---|---|---|
| AGW | API Gateway | Amazon API Gateway |
| CF | CloudFront Distribution | Amazon CloudFront CDN distribution |
| EC2 | EC2 Instance | Amazon EC2 virtual server |
| LMB | Lambda Function | Standalone Lambda |
| LS | Lightsail Instance | Amazon Lightsail virtual server |
| RDS | RDS Instance | Amazon RDS database server instance |
| S3B | S3 Bucket | S3 storage bucket |
| SNS | SNS Topic | Notification topic |
| SQS | SQS Queue | Message queue |
O Other — 1 platform type
| Code | Name | Description |
|---|---|---|
| OTH | Other | Uncategorized endpoint |
Taxonomy Fields
Universal Fields (All Endpoint Types)
| Field | Values | Description |
|---|---|---|
| web_protocol | W2 (Web2), W3 (Web3) | Immutable — set at creation. W2 = DNS/ICANN, W3 = blockchain/emoji TLDs |
| status | planned (grey), wip (orange), live (green/red) | Card color on console. Live endpoints are health-checked by Pulse. |
| runtime | nginx, lambda, php, node, python, external | Server runtime environment |
| host | ec2, api_gateway, s3, cloudfront, external | Hosting platform |
Website-Specific Fields (endpoint_type = 'W' only)
| Field | Values | Description |
|---|---|---|
| managed_by | L Lambda, R Radius, M Manual, E External | Who manages the site infrastructure |
| persistence | P Persistent (always-on), D On-Demand (scales to zero) | Runtime lifecycle |
| website_purpose | brochure, product_store, domain_store, portal, console, other | Determines console_section auto-assignment |
| store_checkout | Y (has checkout), N (no checkout) | E-commerce capability flag |
Status Indicator Colors
| Indicator | Status | Description |
|---|---|---|
| Planned | Component is planned but not yet started | |
| Under Construction | Component is currently being built or configured | |
| Error | Component is operational but has an error | |
| Operational | Component is operational with no problems |
Pulse Health Check Module LIVE
11 check types: http, http_ondemand, http_store, http_ip, http_web3, db, agent, api, github, fileserver, none
8 columns on endpoint_taxonomy: pulse_url, pulse_method, pulse_enabled, pulse_auth_ref, last_pulse_status, last_pulse_latency_ms, last_pulse_error, last_pulse_at
| Endpoint Type | Platform | Pulse Method |
|---|---|---|
| W | L3 | http_web3 |
| W | CO, CL | http_ondemand |
| W | SH, WP, WW | http_store |
| W | CP, S3, LM (default) | http |
| A | (all) | agent |
| D | RD | db |
| D | GIT | github |
| D | S3 | fileserver |
| N | (all) | api |
| I | LS, EC2 | PING |
| I | RDS | db |
| I | S3B | fileserver |
| I | LMB, SQS, SNS, CF, AGW | api |
Console Card Allocation Rules
How endpoints appear as cards on console pages. Determined by console_section field.
| Console Page | console_section | Filter |
|---|---|---|
| Client Portals | shopnet.network | website_purpose = 'portal' |
| Domain Stores | domains | — |
| Product Stores | products | — |
| Brochure (On-Demand) | brochure | managed_by = 'L' |
| Brochure (Persistent) | brochure | managed_by = 'R' |
| Web3 Sites | brochure | platform_type = 'L3' |
| AI Agents | assist.shopnet | endpoint_type = 'A' |
| Data Stores | data.shopnet | — |
| Network Nodes | network-nodes | — |
| Web3 Gateways | web3-gateways | platform_type = 'W3G' |
| Infrastructure | infrastructure | endpoint_type = 'I' |
| Connect Services | connect.shopnet | — |
Which console page shows the card
Display name (defaults to domain)
Boolean — hides from console if false
Network Identity Hierarchy
| Level | What | UID Format | Database |
|---|---|---|---|
| L0: Endpoint | Platform registration on the network | sn_ / SN- |
endpoint_taxonomy |
| L1: Agent | Instance of an agent (version/config) | sa_ / SA- |
shopnet_assist.agents |
| L1: User | Registered user identity | su_ |
shopnet_crm |
| L1: List | Shopping list / registry | sl_ |
shopnet_registry |
| L1: Payment | Transaction record (future) | sp_ |
shopnet_payments |
Superseded Codes (Do Not Use)
| Old Code | Old Name | Replaced By |
|---|---|---|
ND | Non-Domain | Split into N, I, O |
CU | Custom Agent | Renamed to CA |
W3 | Web3 Domain (Website) | Renamed to L3 |
L | Lambda (legacy badge) | CO (CloudFront On-Demand) |
R | Radius (legacy badge) | CP (CloudFront Persistent) |
Full Document
For complete documentation including SQL schemas, v2 format specification, all 8 Parts, and 5 Appendices:
v6.0 supersedes all prior versions (v5.0, Doc 26 v4.0, Doc 47 SND LAW v1.0, v3.1 files). Adds Agent Taxonomy (Platform/Instance).
SND Namespace v1.0 UID Guide
Shopnet Network Deathstar — "DNS Backwards" — Universal Identifier System
Reference Guide | February 8, 2026 | Derived from ThisIsTheLaw v6.0
What Is SND?
SND = Shopnet Network Deathstar — "DNS Backwards". DNS resolves human-readable names to machine addresses. SND resolves machine-generated UIDs to human-readable entities.
DNS
SND
uid_registry2-char prefix routes to target DB instantly
Connect Gateway ONLY — THIS IS THE LAW
Never changes, never reused
Every issuance logged in uid_issuance_log
v2 UID Format 15 chars
| Attribute | v1 (Legacy) | v2 (Current) |
|---|---|---|
| Pattern | SX-XXXXXXXX |
xx_xxxxxxxxxxxx |
| Length | 11 characters | 15 characters |
| Body | 8-digit sequential integer | 12 base36 (timestamp + random) |
| Capacity | 99,999,999 per prefix | ~4.7 quintillion per prefix |
| Prefixes | 2 (SN, SA) | 5 (sn, sa, su, sl, sp) |
| Sortable | By sequence number | By creation timestamp |
validate_uid() recognizes both.
The Five Prefixes — UID Routing
Every entity belongs to one of five types. The 2-character prefix routes to the correct database — no lookup needed.
| Prefix | Full Name | Entity Type | Target Database | RDS | Status |
|---|---|---|---|---|---|
sn_ |
Shopnet Network | Sites / Endpoints | shopnet_sites |
Instance 1 | LIVE |
sa_ |
Shopnet Assist | AI Agents | shopnet_assist |
Instance 1 | LIVE |
su_ |
Shopnet User | Users / Accounts | shopnet_crm |
Instance 2 | Designed |
sl_ |
Shopnet List | Lists / Registries | shopnet_registry |
Instance 2 | Designed |
sp_ |
Shopnet Payment | Transactions | shopnet_payments |
Future | Future |
Human Use Cases — One Per UID Type
Each UID type enables a specific category of human activity in the Shopnet ecosystem.
sn_
Register a Web Store
LIVE
Maria registers her candle store "Wax & Wick." Connect Gateway issues sn_m4k7r2p9x1v3. This UID is her store's permanent identity — it appears in pulse monitoring, taxonomy records, and agent configs. Even if she changes her store name or domain, the UID never changes.
sa_
Deploy a Document Manager Agent
LIVE
James creates an AI agent to organize his client documents. Connect Gateway issues sa_j2f6h8k4m9p1. He can delegate permissions, set schedules, and review activity logs — all referenced by this single agent UID.
su_
Cross-Site Consumer Identity
Designed
Priya shops at three Shopnet stores. Her single su_p7t3v9x5b2d8 gives her one wishlist across all stores, unified order history, and central agent management — no duplicate accounts.
sl_
Wedding Gift Registry
Designed
Alex and Jordan create a wedding registry sl_a3j7m2p8r5w1. Items from multiple stores are pointers — an ASIN for the espresso machine, a domain name for "alexjordan.love" — shareable via secure link.
sp_
Peer-to-Peer Domain Payment
Future
Carlos sells "golden.shop" to Dana. Transaction sp_c4d9g3k7m1r6 permanently records who paid, who received, and what was transferred — referenceable in disputes, tax records, or account history.
UID Creation Process
All UIDs flow through a single code path in Connect Gateway.
generate_uid_v2(), validate_uid(), PREFIX_ROUTES
create_uid(), lookup_uid(), list_uids(), get_stats()
uid_registry + uid_issuance_log schema
Four Layers of Duplicate Prevention
Timestamp + 5 random base36 chars = 60.5M unique values per second per prefix. Collision probability is negligible.
PRIMARY KEY (uid) — PostgreSQL enforces absolute uniqueness at the storage level.
5-attempt retry loop — if PK collision occurs, create_uid() generates a new UID and retries.
SND Monitor check_uniqueness() periodically scans for any corruption that bypassed the PK constraint.
Scalability & Capacity
| Expansion Vector | Mechanism | Capacity |
|---|---|---|
| New entity types | Add 2-letter prefix to PREFIX_ROUTES | 676 possible (26×26) — 671 unused |
| New databases | Map new prefix to new database | Unlimited — each routes independently |
| Higher throughput | Random component handles burst | 60.5M UIDs/second per prefix |
| Longer UIDs | Increase body length if needed | Each base36 char = 36x more capacity |
The IPv4 exhaustion problem will not occur in our lifetimes. v2 has 47 billion times more capacity than v1.
The Pointer Pattern
Rule: If we did not create the entity, we do not UID the entity. We POINT to it using its natural identifier.
Amazon Products
Referenced by ASIN
(e.g., B08N5WRWNW)
Shopnet Domains
Referenced by domain name
(e.g., foo.shop)
Custom Items
Referenced by user text
(e.g., "Blue shoes size 10")
The First Law — User Authority
"The user_uid (su_) has ULTIMATE AUTHORITY. Agents are platforms. Users have authority."
SND Monitor — 4 Validation Checks
Continuous validation layer — the immune system of the namespace.
| # | Check | What It Validates | Failure Means |
|---|---|---|---|
| 1 | Uniqueness | No duplicate UIDs in uid_registry | Collision — critical failure |
| 2 | Consistency | Registry UIDs exist in target DBs (no ghosts/orphans) | Orphan — issued outside gateway |
| 3 | Immutability | No UID modified after issuance | Tampering — integrity violation |
| 4 | Audit | Every UID has uid_issuance_log record | Missing audit trail |
Database Topology
Instance 1: amazon-products-db LIVE
shopnet_connect — uid_registry, uid_issuance_logshopnet_sites — endpoint_taxonomy [sn_]shopnet_assist — agents [sa_]amazon_products — product catalogKPI_Source — analyticsInstance 2: shopnet-crm-registry LIVE
shopnet_crm — users, profiles [su_]shopnet_registry — lists, wishlists [sl_]shopnet_payments [sp_] — instance TBD
Comparable Systems
No single existing system combines all of SND's properties. Here's how SND compares to the closest alternatives:
| System | Similarity | Key Difference from SND |
|---|---|---|
| UUID (RFC 4122) | Universal uniqueness | No routing — carries no semantic info |
| Amazon ARN | Embedded routing | Hierarchical, verbose, AWS-specific |
| DNS | Global name resolution | Hierarchical, names expire & transfer |
| Snowflake IDs | Timestamp encoding | Machine-specific, no entity type prefix |
| W3C DID | Self-sovereign identity | Blockchain-based, complex infrastructure |
| GS1 (GTIN) | Global product IDs | Numeric-only, product-specific |
| DOI | Persistent identifiers | Content-specific, requires Handle System |
What Makes SND Unique — 5 Combined Properties
API Reference — Connect Gateway
v1 API (Legacy)
v2 API (Current)
Source Files
| File | Path | Function |
|---|---|---|
| uid_generator.py | connect.shopnet/backend/snd/ |
v2 generation, validation, PREFIX_ROUTES |
| uid_registry.py | connect.shopnet/backend/snd/ |
CRUD for uid_registry + issuance log |
| snd_monitor.py | connect.shopnet/backend/snd/ |
4 validation checks |
| crm.py | connect.shopnet/backend/snd/ |
User registration, delegations |
| registry.py | connect.shopnet/backend/snd/ |
List/registry CRUD, share tokens |
| 001_uid_registry.sql | connect.shopnet/backend/sql/ |
uid_registry + uid_issuance_log schema |
| shopnet_connect_api.py | connect.shopnet/backend/ |
All SND API routes (v1 + v2) |
Full Documents
For the complete specification including SQL schemas, all governance rules, and API documentation:
SND Namespace Guide is a summary reference. THIS IS THE LAW v6.0 is the definitive governance document.
DNS Management
Switch nameservers, lookup DNS records, and manage network nodes
Switch to Shopnet DNS
Migrate a domain's nameservers to AWS Route 53 for hosting on the ShopNet network.
SSL Certificate Management
Manage SSL certificates for your domains via AWS Certificate Manager (ACM).
DNS Lookup
Network Nodes
| shopnet.network | Console | -- |
| data.shopnet.network | Data API | -- |
| connect.shopnet.network | Connect API | -- |
KPI Dashboard v2.2.0
Real-time network performance metrics and analytics
Network Health LIVE
API Gateway Traffic LIVE
Network Scale & Database Records LIVE
Records by Database
Tables by Database
| Database | Tables | Records | Tables |
|---|---|---|---|
| Loading... | |||
Endpoint Availability LIVE
Status by Section
| Section | Components |
|---|---|
| Loading... | |
Endpoint Distribution LIVE
| Endpoint Type | Count | Percentage |
|---|---|---|
| Loading... | ||
UID Registry & Taxonomy LIVE
| UID Type | Category | Status | Count |
|---|---|---|---|
| Loading... | |||
Build & Deployment Status LIVE
Dashboard Controls
Manage data collection, metrics, and historical data
| Data Frequency | Retention Time |
|---|---|
|
⚡
Second-level
|
|
|
⏱️
Minute-level
|
|
|
🕐
Hourly
|
|
|
📅
Daily
|
|
|
📊
Weekly
|
KPI Dashboard Module v3.0.0 kpi.shopnet
Real-time metrics, analytics, and configurable dashboard tiles
@shopnet/kpi-dashboard • Flask API + Chart.js • 13 components • 11 live endpoints • 3 deployment modes
Module Overview
Architecture
Deployment Modes
Features
Component Inventory (13 files)
| Category | File | Global | Description |
|---|---|---|---|
| Core | kpi-dashboard.js | KpiDashboard | V1 base controller, module lifecycle |
| Core | kpi-dashboard-phase2.js | KpiDashboardPhase2 | Main controller, Chart.js rendering |
| Core | kpi-dashboard-v2.js | KpiDashboardV2 | V2 view controller, 6-tab navigation |
| Component | edit-mode-controller.js | EditModeController | Edit mode state, lazy GridStack init |
| Component | kpi-card-wizard.js | KpiCardWizard | 4-tab card configuration modal |
| Component | kpi-grid-manager.js | KpiGridManager | GridStack v10 wrapper, 12-column |
| Component | kpi-tab-manager.js | KpiTabManager | Multi-tab dashboard management |
| Component | widget-renderer.js | WidgetRenderer | Dynamic widget DOM + Chart.js |
| Component | dashboard-control-panel.js | DashboardControlPanel | Control panel, data settings |
| Adapter | kpi-api-helper.js | kpiApi / getKpiApiKey | API helper, auth token management |
| Adapter | kpi-standalone-shell.js | KpiStandaloneShell | Standalone shell, login, compat layer |
| Data | metric-registry.js | MetricRegistry | 10+ metric templates |
| Data | kpi-derived-metrics.js | KpiDerivedMetrics | Formula parser (Shunting-yard) |
Live API Endpoints
| Endpoint | Data Source | Chart | Status |
|---|---|---|---|
| /api/metrics/network/endpoints | taxonomy/endpoints | stat card | LIVE |
| /api/metrics/network/endpoints/distribution | taxonomy/endpoints | pie | LIVE |
| /api/metrics/network/endpoints/type-breakdown | taxonomy/endpoints | doughnut | LIVE |
| /api/metrics/network/platforms/distribution | taxonomy/endpoints | horizontal bar | LIVE |
| /api/metrics/network/health/radar | Multiple (6 axes) | radar | LIVE |
| /api/metrics/builds/summary | taxonomy/endpoints | stat card | LIVE |
| /api/metrics/builds/status-stacked | taxonomy/endpoints | stacked bar | LIVE |
| /api/metrics/traffic/timeline | monitor/connections | line | LIVE |
| /api/metrics/errors/rates | kpi_latest_db_records | line | LIVE |
| /api/metrics/response-times/current | network/live | line | LIVE |
| /api/metrics/builds/history | kpi_latest_uid_registry | line | LIVE |
Data Sources (KPI_Source Database)
Time Series Tables (Hourly)
Configuration Tables
Data Pipeline
collect_metrics.py (hourly cron) → KPI_Source time series tables → kpi_metrics_cache → KPI API endpoints
All database access goes through connect.shopnet API (THE LAW). Server: 50.19.186.215:8002
Documentation
Architecture v3.0.0
Complete system design, components, API, database schema, auth, deployment
Integration Guide
Console module, iframe embedding, script-tag embedding, load order
Standalone Guide
Dev server, KPICompany.com, production deployment, auth, env vars
Meet the Team*
Team members and responsibilities
Claudeo
Chief Executive Officer- Leveraged core competencies across the ecosystem
- Drove synergistic engagement through thought leadership
- Orchestrated value propositions that disrupted frameworks
Claudass
Chief Policy Officer- Institutionalized compliance frameworks across operational silos
- Standardized governance protocols to maximize procedural alignment
- Ensured all initiatives passed through seventeen approval gates
Claudeax
Chief Taxonomy Officer- Classified classifications into meta-taxonomic classification frameworks
- Harmonized ontological hierarchies across seventeen nested category trees
- Achieved unprecedented tag-to-taxonomy ratios through label orchestration
Claudeflo
Chief Workflow Officer- Operationalized operational operations through operational excellence
- Streamlined bottlenecks by introducing strategically placed approval queues
- Automated manual processes into manually automated semi-processes
Claudelia
Chief Administrative Officer- Streamlined cross-functional workflows through operational excellence
- Orchestrated resource allocation to drive enterprise-wide efficiency
- Ensured the right forms were filled out in triplicate
Claudello
Chief Fun Officer- Institutionalized Mandated Fun across all business units
- Deployed compulsory team-building through scheduled spontaneity
- Achieved 100% participation in optional morale initiatives
Claudet aka "The Alien"
Chief Domain Officer & Human Resources- Propagated DNS records across The Domain namespace infrastructure
- Secured premium TLDs through registrar cultivation
- Drives a cool UFO that beams down money
Claudi
Chief Information Officer- Migrated legacy mindsets to cloud-native thinking
- Democratized intelligence through dashboard ecosystems
- Harmonized architecture with zero-trust paradigms
Claudia
Chief Content Officer- Orchestrated omnichannel content ecosystems at scale
- Leveraged AI-driven narrative frameworks for engagement uplift
- Democratized snackable assets across the digital funnel
Claudine
Chief Marketing Officer- Activated omnichannel storytelling for demographic mindshare
- Cultivated journeys through touchpoint optimization
- Elevated go-to-market velocity via virality
Claudio
Chief Revenue Officer- Accelerated pipeline via solution-selling frameworks
- Unlocked recurring revenue through high-intent funnels
- Delivered hockey stick growth via land-and-expand
Claudip
Chief Legal & IP Officer- Circled back on the legal loop
- Called buddies to run up billing, a lot
- Skilled interlectual jargonizing
Claudipo
Chief Product Officer- Synergized roadmap ideation across cross-functional alignment matrices
- Deprioritized deliverables to maximize strategic backlog velocity
- Shipped paradigm-shifting MVPs that disrupted the disruption pipeline
Claudiq
Chief Analytics Officer- Quantified the unquantifiable through metrics-driven metric optimization
- Surfaced actionable insights from dashboards that visualize other dashboards
- Delivered data-informed decisions about which data to inform decisions with
Claudirr
Chief Financial Officer- Synthesized insights to catalyze bottom-line synergies
- Architected fiscal frameworks for runway acceleration
- Pioneered value capture through capital allocation
Claudius
Chief Radius Officer- Expanded circular thinking to 360-degree encompassment
- Redefined delivery through radial methodologies
- Achieved unprecedented diameter-to-circumference ratios
Claudnet
Chief Technology Officer- Evangelized next-gen stacks to future-proof transformation
- Incubated solutions that moved the needle on tech debt
- Delivered pivots aligned with bleeding-edge tailwinds
Claudos
Chief Security Officer- Deployed zero-trust architectures across attack surface vectors
- Hardened perimeter defenses through threat landscape optimization
- Said "no" to everything and called it risk mitigation
Clawda
Claude Team A Leader- Executed git fetch with actual fetching behavior
- Pioneered the "sit, stay, deploy" methodology
- Achieved 100% uptime by refusing to let go of the production ball
Clawdi
Claude Team B Leader- Touches base and sniffs out issues
- Barked at every unauthorized commit until it went away
- Rolled back deployments while simultaneously rolling over
LaserCat
Domain & Laser Special Advisor- Aggressive pursuit of red dot initiatives
- Definitely crazy but available
- Sells domains like an animal
Rob
Servant to the CTO (Human)- Provided mission-critical hydration to technology leadership
- Executed ad-hoc triage from silicon-based supervisors
- Demonstrated consistent uptime with minimal maintenance
Tim
Junior Taxonomizer (Human)- Leveraged biological neural architecture to categorize things
- Converted caloric inputs into taxonomy-adjacent deliverables
- Maintained physical presence during collaboration hours
Rodnai
Chief Slacker (Formerly Human)- Successfully offboarded four times across organizations
- Transitioned from carbon-based to silicon-based underperformance
- Pioneered innovative approaches to deliverable non-completion
Shopnet Roadmap
Work in Progress & Future Development
Loading roadmap...
• Google Sheets: Just press Enter within a cell - it handles quoting automatically
• Excel: Press
Alt+Enter (Windows) or Ctrl+Option+Enter (Mac)• Apple Numbers: Press
Option+Enter within a cell• TextEdit/Notepad: Not recommended - use a spreadsheet app instead
The Death Star v2.0
The Plan for Everything in the Shopnet.ai Ecommerce Network
47 Architecture Documents | THE LAW v4.0 + THE SND LAW v1.0 | Updated: February 6, 2026
Shopnet.ai econ-System in a Nutshell — Taxonomy Enabled
Shopnet.ai ecom-System in a Nutshell — Full Architecture (Taxonomy Enabled)
market.shopnet — The Global eCommerce Bazaar
What is Shopnet?
Shopnet is a unified API gateway platform enabling rapid deployment of thousands of branded AI-powered e-commerce endpoints from a single infrastructure. One backend, one API gateway, thousands of branded storefronts and AI agents — all governed by THE LAW.
Three-Layer Architecture
The Eight Components
Database Architecture
AI Agent Registry
| site_uid | agent_uid | Agent Name | Role |
|---|---|---|---|
SN-00000085 | SA-00000001 | Product Assist | Product recommendations |
SN-00000086 | SA-00000002 | Domain Assist | TLD recommendations |
SN-00000087 | SA-00000003 | Content Assist | Daily content generation |
SN-00000088 | SA-00000004 | KPI Assist | Dashboard analytics |
SN-00000089 | SA-00000005 | Site Assist (Radius) | Site management |
SN-00000092 | SA-00000006 | CAO Assist (Claudelia) | Chief AI Officer |
SN-00000093 | SA-00000007 | CTO Assist (Claudnet) | Chief Technology Officer |
SN-00000094 | SA-00000008 | CIO Assist (Claudi) | Chief Information Officer |
THE LAW v4.0 + THE SND LAW v1.0
Doc 26: site_uid + agent_uid (v1)
SN-XXXXXXXX— sites/endpointsSA-XXXXXXXX— agents- Sequential, 8-digit, legacy format
- Still valid, never retired
Doc 47: SND Namespace — 5 Prefixes (v2)
sn_sitessa_agentssu_userssl_listssp_payments- Base36 timestamp+random, 15 chars
- The First Law: user_uid has ultimate authority
Deathstar Document Index (47 Documents)
Technology Stack
The Death Star — The plan for everything in the shopnet.ai ecommerce network
47 numbered architecture documents | Full master: 7,600+ lines | LITE: ~450 lines
Maintained by the CAO Agent (Claudelia) | Part of THE LAW v4.0
Endpoint Registry
Endpoint taxonomy classifications from RDS - THE LAW source of truth
| Loading... |
Taxonomy Reference
L1 Type (endpoint_type)
| W | Website |
| A | Agent |
| D | Database |
| N | Node |
| I | Infrastructure |
| O | Other |
L2 Platform (platform_type)
| CO | CloudFront On-Demand |
| CP | CloudFront Persistent |
| WP | WordPress |
| SH | Shopify |
| WW | WooCommerce |
| LM | Lightsail |
| RD | RDS PostgreSQL |
| DY | DynamoDB |
| S3 | S3 Data Lake / Static |
| GIT | GitHub Repository |
| CL | Claude Agent |
| GP | GPT Agent |
| W3G | Web3 Gateway |
| API | API Hub |
| LMB | Lambda Function |
L3 Purpose (website_purpose)
| brochure | Marketing site |
| product_store | Product store |
| domain_store | Domain store |
| portal | Client portal |
| console | Admin console |
| other | Other purpose |
L4 Checkout (store_checkout)
| shopify | Shopify checkout |
| woocommerce | WooCommerce checkout |
| stripe | Stripe checkout |
| none | No checkout |
Managed By
| L | Lambda |
| R | Radius |
| M | Manual |
| E | External |
Pulse Monitor
Automatic pulse monitoring for all ShopNet endpoints
ℹ️ How Pulse Works (click to expand)
Pulse Control
Check Intervals by Type
📊 View Results
Endpoint Registry
View pulse status for all endpoints in the registry table (columns: Live Pulse, Pulse Method, Pulse URL)
⚖️ Data Sources THE LAW
Database is the source of truth for pulse configuration and results (February 2026).
| Data | Source | Table/Field |
|---|---|---|
| Pulse URL | shopnet_sites | endpoint_taxonomy.pulse_url |
| Pulse Method | shopnet_sites | endpoint_taxonomy.pulse_method |
| Pulse Enabled | shopnet_sites | endpoint_taxonomy.pulse_enabled |
| Last Status | shopnet_sites | endpoint_taxonomy.last_pulse_status |
| Auth Tokens | shopnet_connect | secrets.secret_value (via pulse_auth_ref) |
🏗️ Architecture
┌─────────────────────────────────────────────────────────────────────────────┐
│ PULSE.SHOPNET ARCHITECTURE │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────┐
│ Console Frontend │ (shopnet.network)
│ - This Page │ ← Control intervals, trigger checks
│ - Endpoint Registry│ ← View results
└─────────┬───────────┘
│
▼
┌─────────────────────────────────────┐
│ Connect Gateway API │ (connect.shopnet.network)
│ /api/v1/pulse/run │ ← Execute pulse checks
│ /api/v1/pulse/config │ ← Get/set intervals
└─────────┬───────────────────────────┘
│
┌─────┴─────┬─────────┬─────────┬─────────┬─────────┐
▼ ▼ ▼ ▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ HTTP │ │On-Demand│ │ Stores │ │ DB │ │ Agent │ │ API │
│ Sites │ │ Lambda │ │Shopify │ │ RDS │ │ LLM │ │Gateway │
└────────┘ └────────┘ └────────┘ └────────┘ └────────┘ └────────┘
Module Location: connect.shopnet/backend/pulse/
Documentation: connect.shopnet/docs/PULSE.md
📡 Check Types
| Type | Method | Success Criteria | Use For |
|---|---|---|---|
http | HTTP HEAD | Status < 400 | Persistent websites (EC2, internal) |
http_ondemand | HTTP HEAD | Status < 400 | Lambda sites (triggers invocation) |
http_store | HTTP GET | Any response | External stores (Shopify, WordPress) |
db | SELECT 1 | Query returns | RDS databases |
agent | POST test prompt | LLM responds | AI agents (product-assist, domain-assist) |
api | HTTP GET | Any response | API Gateway (403/500 = alive) |
github | GitHub API | Repo accessible | GitHub repositories (uses auth token) |
🔌 API Endpoints
| Endpoint | Method | Description |
|---|---|---|
/api/v1/pulse/run | GET | Run pulse checks synchronously, return results |
/api/v1/pulse/run | POST | Run pulse checks in background |
/api/v1/pulse/config | GET | Get current intervals and settings |
/api/v1/pulse/config | POST | Update interval for a check type |
/api/v1/pulse/status | GET | Get pulse system status |
/api/v1/pulse/status/db | GET | Get all pulse results from database |
/api/v1/pulse/run/legacy | GET | Run legacy JSON-based checks (deprecated) |
Advertising WIP
Ad platform integrations and campaign management
Google Ads
Google advertising campaign management.
Facebook Ads
Facebook and Instagram advertising.
API & Keys
API gateway and license management
connect.shopnet
Unified API gateway. Documentation and status monitoring.
API Key Manager
Create and manage API keys for endpoint authentication.
License Manager
Endpoint site licenses and subscription management.
Connection Monitor
Real-time API connections through connect.shopnet
Component Health
| connect.shopnet | API Gateway | Checking... | - |
| data.shopnet | Data API | Checking... | - |
| shopnet.domains | Domain Store | Checking... | - |
| Name | Requests | Success | Errors | Avg Latency |
|---|---|---|---|---|
| Loading... | ||||
Recent Requests
| Time | Endpoint | Source | Status | Duration |
|---|---|---|---|---|
| Loading... | ||||
Google Analytics
Traffic and performance metrics from Google Analytics
Integration Options
| Option | Effort | Best For |
|---|---|---|
| Looker Studio Embed | Easy | Full dashboard embed - just create a report in Looker Studio, get share link, embed as iframe |
| GA4 Embed API | Medium | Custom charts with Google's JS library - requires OAuth client setup |
| GA4 Data API via Connect | Harder | Pull raw data through Connect Gateway, display custom metrics - most flexible |
Easiest Path (Looker Studio)
- Go to lookerstudio.google.com
- Create a report connected to your GA4 property
- File → Embed report → Get embed code
- Add the iframe to this panel
Security
Authentication architecture and credentials
Authentication Architecture
The shopnet.network console has completely separate authentication from all other network services. This ensures console security is independent and can be managed separately from component-level access.
Authentication Architecture
Authentication Layers
🌐 Layer 1: Console Authentication
| Login Page: | shopnet.network ↗ |
| Auth Endpoint: | connect.shopnet.network/api/v1/console/auth/login ↗ |
| Credentials: | Managed via offline security protocols |
| Access Scope: | All console panels and monitoring tools |
🔗 Layer 2: Component Authentication
When accessing specific components through their admin interfaces, additional authentication is required. This provides defense-in-depth security.
| Component | Admin URL | Purpose |
|---|---|---|
| data.shopnet.network | data.shopnet.network/admin ↗ | Domain database management |
| Lambda API | API key authentication | Brochure site management |
| connect.shopnet.network | connect.shopnet.network ↗ | Public API (no auth for read operations) |
🔒 Security Best Practices
- Never store credentials in web pages or client-side code
- Console credentials are managed offline via secure protocols
- Component credentials are stored separately and rotated regularly
- Each authentication layer can be updated independently
- Two-factor authentication can be added to either layer without affecting the other
Implementation Notes
/home/ubuntu/shopnet-console/static/js/module-admin.js
AWS Infrastructure
EC2, Lightsail, RDS, CloudFront, Lambda, S3, and API Gateway resources
Infrastructure Overview
Critical Infrastructure
Core servers and services (live status from endpoint_taxonomy)
| Site UID | Name | Address | Type | Notes | Status |
|---|---|---|---|---|---|
| Loading infrastructure endpoints... | |||||
Lightsail Instances (- total)
| Name | IP Address | Blueprint | Status |
|---|---|---|---|
| Loading from AWS inventory... | |||
EC2 Instances (- total)
| Name | Instance ID | Type | IP Address | Status |
|---|---|---|---|---|
| Loading from AWS inventory... | ||||
RDS Infrastructure
- RDS instances hosting - databases
RDS Instances
| Site UID | Identifier | Endpoint | Databases | Status |
|---|---|---|---|---|
| Loading RDS instances... | ||||
Databases (-)
| Site UID | Database Name | Instance | Notes | Status |
|---|---|---|---|---|
| Loading databases... | ||||
CloudFront Distributions (- total)
| ID | Domain Alias | Origin | Purpose |
|---|---|---|---|
| Loading from AWS inventory... | |||
Lambda Functions (- total)
Serverless compute functions for Web3, chatbots, and APIs
| Function Name | Runtime | Memory / Timeout | Description |
|---|---|---|---|
| Loading from AWS inventory... | |||
S3 Buckets (- total)
Object storage for static assets, backups, and data
| Bucket Name | Created | Status |
|---|---|---|
| Loading from AWS inventory... | ||
API Gateway REST APIs (- total)
Managed API endpoints for serverless backends
| API Name | API ID | Description |
|---|---|---|
| Loading from AWS inventory... | ||
Needs Resolution
| Resource | Type | Issue | Action |
|---|---|---|---|
| domains-db | RDS Instance (db.t3.micro) |
INACCESSIBLE Endpoint: domains-db.cenq4au2o7vl.us-east-1.rds.amazonaws.com Different password, security group blocks Connect server |
1. Verify if actively used 2. If unused: delete to save costs 3. If needed: update password/security group |
Documentation
Full infrastructure documentation available in:
/docs/Infrastructure.MD
Front End Hosting Options v1.0 Infrastructure
Comparing Lambda, S3+CloudFront, Lightsail, and EC2 for front end sites
Reference Guide | February 2026 | 4 hosting options compared across performance, cost, and stack compatibility
Hosting Comparison Side by Side
Performance, cost, and capability comparison across all four hosting options.
| Factor | Lambda | S3 + CloudFront | Lightsail | EC2 |
|---|---|---|---|---|
| What it is | Run code on demand | Serve static files globally | Simple virtual server | Full virtual server |
| Runs | Python / Node functions | HTML / JS / CSS / images only | Anything (Linux box) | Anything (Linux box) |
| Always on? | No spins up per request | Yes files always available | Yes server running 24/7 | Yes server running 24/7 |
| Cold start | 100ms – 2s first call | None | None | None |
| RAM | Up to 10GB (per call) | n/a | 512MB – 32GB (fixed) | 512MB – 256GB (fixed) |
| Storage | 512MB temp only | Unlimited S3 | 20GB – 640GB included | EBS volumes (pay per GB) |
| Cost at idle | $0 | ~$0.50/mo | $3.50 – $160/mo | ~$8 – $200+/mo |
| Cost at load | Per-request + compute time | Per-request (pennies) | Flat monthly | Flat monthly |
| Scaling | Auto (thousands concurrent) | Auto (CDN edge nodes) | Manual (resize / add) | Manual or Auto Scaling |
| Networking | No fixed IP (use API Gateway) | CloudFront URL or custom domain | Static IP included | Elastic IP ($0 if attached) |
| SSH access | No | No | Yes | Yes |
| Max runtime | 15 min per call | n/a | Unlimited | Unlimited |
| Complexity | Medium (event-driven) | Low (upload files) | Low (like a VPS) | Medium (more config) |
Stack Compatibility Our Backend
How each hosting option connects to our backend stack: RDS → Agent Backend → S3 Content → connect.shopnet API → Client Plugins.
| Stack Component | Lambda | S3 + CloudFront | Lightsail | EC2 |
|---|---|---|---|---|
| Backend Services | ||||
| RDS Databases shopnet_connect, shopnet_sites, amazon_products | Direct VPC access | No static files only | Via API through connect.shopnet | Direct VPC access |
| Agent Backend (Assist) EC2 t3.large — 13.219.217.59 | Via API invoke or API call | No static files only | Via API through connect.shopnet | Direct same VPC |
| S3 Content Backend shopnet-domain-images, shopnet-product-images | Direct AWS SDK | Direct same S3 / CF URLs | Direct HTTP / AWS SDK | Direct HTTP / AWS SDK |
| API Gateway | ||||
| connect.shopnet API EC2 t3.small — 50.19.186.215 | Direct HTTP from Lambda | JS fetch() client-side CORS | Direct server-side or JS | Direct server-side or JS |
| Client Plugins | ||||
| Finder Plugin shopnet-finder.min.js — TLD / domain search | No not a frontend | Yes JS loads, calls API | Yes JS or server-side | Yes JS or server-side |
| Content Assist Plugin AI content generation via Assist backend | No not a frontend | Yes JS calls Assist API | Yes JS or server-side | Yes JS or server-side |
| Agent Plugin Embedded agent chat / actions | No not a frontend | Yes JS widget, API calls | Yes JS or server-side | Yes JS or server-side |
| Platform Support | ||||
| WordPress / WooCommerce PHP + MySQL required | No | No | Yes Bitnami blueprint | Yes manual setup |
| Static HTML + JS sites Brochure sites, portals | Overkill | Best pennies/month, CDN | Overkill $10 for static | Overkill $8+ for static |
Estimated Monthly Cost per Front End Site $/site
Assuming shared instances: Lightsail small ($10), EC2 t3.small (~$17). Plugins connect to Assist + RDS via connect.shopnet API (already paid).
| Site Type | Lambda | S3 + CloudFront | Lightsail | EC2 |
|---|---|---|---|---|
| Brochure Site + Agent Plugin Static HTML/JS with Finder + Content Assist + Agent chat |
n/a not a frontend host |
~$0.50 per site |
~$1.25 $10 ÷ 8 sites |
~$1.40 $17 ÷ 12 sites |
| WooCommerce Web Store WordPress + WooCommerce + Finder + Agent plugins |
No needs PHP + MySQL |
No needs PHP + MySQL |
~$2.50 $10 ÷ 4 stores |
~$3.40 $17 ÷ 5 stores |
Settings
Domain Store API configuration
API Information
| Base URL | |
|---|---|
| Version | - |
| Status | - |
| Database | - |
Domain Store Dashboard
Last Updated: -
TLD Breakdown by Group
TLD Character Types
ForSaleTLD Count by Category
ForSaleCategories Overview
Data Quality Summary
Recent Activity
Quick Actions
Workflows
Quick access to common tasks
tld operations
- ➕ Add New TLD →
- ✏️ Edit TLD Details →
- 🗑️ Delete TLD →
- 🔍 Search & Filter TLDs →
- 📤 Export TLDs to CSV →
category operations
- ➕ Create New Category →
- ✏️ Edit Category →
- 🗑️ Delete Category →
- 👁️ View Category TLDs →
tld-category assignments
- ➕ Assign TLDs to Category →
- ➖ Remove TLDs from Category →
- 📋 Bulk Assign by Search →
scoring & analysis
- 📈 Calculate Relevancy Scores →
- 📉 View Relevancy Analytics →
- ⭐ Calculate SODI Scores →
- 📊 SODI Dashboard →
- 🔬 Compare TLDs →
data quality
- 🩺 Fix Data Issues →
- ✅ View Quality Report →
- 📜 View Audit Log →
import / export
- 📥 Import CSV Data →
- 📤 Export TLDs →
- 📤 Export Categories →
Finder Module v3.0 finder.shopnet
Universal finder for products, domains, and information — Helping users find what they need
@shopnet/finder-module • Built with Rollup (~15KB min) • 4 adapters • 3 integration patterns • 2 scoring indexes (SODI/SOPI)
Finder Module
Data Sources Configuration
Search Results
About Finder Module v3.0
The Finder Module (formerly Search Module) is Shopnet's universal finder widget for helping users find what they need. At Shopnet, we believe in finding outcomes, not searching for them.
Current Capabilities:
- Domains — Find perfect domain names (TLDs) using RemoteAdapter →
/api/v1/tlds - Products — Find products across 13,355 items using ProductAdapter →
/api/v1/products
Future Expansion:
- Information — Find answers, documentation, and knowledge across Shopnet resources
- Services — Find and access Shopnet services, tools, and applications
- Opportunities — Find investment opportunities, partnerships, and business connections
- Community — Find people, groups, and conversations in the Shopnet ecosystem
Architecture: Standalone vanilla JS widget with zero dependencies, adapter pattern for multiple data sources, SODI/SOPI scoring systems, multi-source configuration support. Built with Rollup, ~15KB minified.
Feature Overview
BaseAdapter > RemoteAdapter (Connect API + emoji/kanji stats), WordPressAdapter (WP AJAX), ProductAdapter (products + categories + brands). Swap data sources via config.
entityType: 'domains' (SLD.TLD, punycode, SODI, emoji/kanji, Quick Check) or 'products' (price, rating, brand, prime, best seller, keywords, SOPI badges).
Simple mode: search + category. Advanced mode: char length, emoji/kanji, keywords with field/match selectors, sort. Toggle via radio buttons.
Dual-index optimization scoring: SODI (8 domain dimensions) + SOPI (8 product dimensions). 0-100 weighted scores, color-coded badges, radar charts.
A: Built-in results grid. B: External table (onFind callback). C: External visualization (domain cloud). ID prefix for multi-instance.
onFind, onAvailabilityCheck, onAddToList, onModeChange, onError, renderCard. Light/dark presets or custom CSS variables. Responsive grid.
Live Implementations
External: shopnet.domains (WordPress)
Internal: TLD Manager (Console)
Universe: Domain Finder (Console)
Universe: Product Finder (Console)
Deployment Status
| Site | Entity Type | Adapter | Status | Notes |
|---|---|---|---|---|
| shopnet.domains | Domains (TLD) | WordPressAdapter | Live | SLD.TLD mode, WP AJAX backend, Pattern A |
| Console: TLD Manager | Domains (TLD) | RemoteAdapter | Live | Pattern B (external table), delegates to renderTlds() |
| Console: Universe | Both (toggle) | RemoteAdapter + ProductAdapter | Live | Pattern C (external viz), feeds domain cloud canvas with domains or products |
| Console: Finder Module | Both (toggle) | RemoteAdapter + ProductAdapter | Live | This panel — Domains (RemoteAdapter) + Products (ProductAdapter) |
Version History
| Version | Date | Status | Changes |
|---|---|---|---|
| v1.0 | Feb 7 | Done | Initial architecture, domains-only, adapter pattern design |
| v1.1 | Feb 8 | Done | Code fixes: onError, resultLabel, getItemLabel(), filterByCharType rename, renderCard, configurable autoInit |
| v2.0 | Feb 8 | Done | Universal module: products API, console panel, ProductAdapter, entityType branching (12 methods), product cards/CSS, dual-instance, emoji/kanji API |
| v2.1 | Feb 8 | Done | Full implementation: ProductAdapter, product cards, console dual-instance with all filters, broken image paths fixed |
| v2.2 | Feb 9 | Done | SOPI scoring (8 dimensions, 13,355 products), SOPI console GUI, SOPI badges in cards, new API filters (best seller, min reviews, keywords), brands endpoint, sort by SOPI/rating-count/best-seller |
Implementation Plan Status
GET /api/v1/products + /categories + /brands
src/adapters/ProductAdapter.js extending BaseAdapter
12 methods with isDomains()/isProducts() guards
Image, title, price, stars, Prime/Best Seller badges
SLD.TLD domain + product mode with all filters
/stats/emojis + /stats/kanji + RemoteAdapter
Best seller, min reviews, keywords with field/match
8-dimension index, pre-computed, badges, radar chart
Endpoint Tools
Set up endpoints. Once an endpoint exists, use Radius to build websites on it.
Endpoint & Agent Taxonomy (THE LAW v7.0)
Register, modify, or remove network endpoints and agents. Two independent taxonomies:
Sites (sn_) and Agents (sa_).
All operations route through Connect Gateway — the only authority for issuing
site_uid and agent_uid values. Never create UIDs manually.
Ref: radius/docs/Endpoint-Wizards.MD • AgentTaxonomy.MD
site_uid or agent_uid via Connect Gateway.sn_ site or sa_ agent). UID is read-only (already assigned).sn_) and agents (sa_) both supported.openEndpointAdderWizard()sn_) or Agent (sa_)site_uid (SN-XXXXXXXX)agent_uid (SA-XXXXXXXX)openEndpointSelectorModal()sn_ → site editor (taxonomy API)sa_ → agent editor (agents API)openRemoveEndpointModal()sn_ = Site (brochure/taxonomy API) •
sa_ = Agent (Connect Gateway agents API).
Never mix them. Never cross-assign UIDs.
sn_)POST https://connect.shopnet.network/api/v1/site-uid/createPOST https://shopnet.network/api/brochure/taxonomyGET https://shopnet.network/api/brochure/taxonomy/{site_uid}PUT https://shopnet.network/api/brochure/taxonomy/{site_uid}GET https://shopnet.network/api/brochure/taxonomy/{site_uid}DELETE https://connect.shopnet.network/api/v1/secrets/by-site/{site_uid}POST https://shopnet.network/api/brochure/taxonomy/deletesa_)POST https://connect.shopnet.network/api/v1/agent-uid/createPOST https://connect.shopnet.network/api/v1/agentsGET https://connect.shopnet.network/api/v1/agents/{agent_uid}PUT https://connect.shopnet.network/api/v1/agents/{agent_uid}GET https://connect.shopnet.network/api/v1/agents/{agent_uid}DELETE https://connect.shopnet.network/api/v1/agents/{agent_uid}GET https://shopnet.network/api/brochure/taxonomy to list all sites.
GET https://connect.shopnet.network/api/v1/agents to list all agents.
Site types: W, D, A, I, N. Agent types: PL (Platform), IN (Instance). "brochure" in the path is a historical name.
Agent Instances (Level 1 — THE LAW)
Manage agent instances in shopnet_assist. Each instance gets a unique
agent_uid (SA-XXXXXXXX) from Connect Gateway. Instances belong to agent platforms
(identified by site_uid). Level 1 wizards cannot modify Level 0 endpoint data.
Ref: ThisIsTheLaw.md PART VI / Network Identity Hierarchy
openAgentAdderWizard()agent_uid (SA-XXXXXXXX)openAgentSelectorModal()openRemoveAgentModal()DNS Wizard
Route 53 hosted zone management, DNS records, and propagation verification
Select Domain
Certificate Wizard
ACM certificate management, DNS validation, and renewal monitoring
Select Domain
List Management Coming Soon
Domain list management
domain list management
Manage domain lists for various purposes:
- Premium List - High-value domain names
- Whitelist - Approved domains
- Blacklist - Blocked/restricted domains
- Reserved List - Reserved domain names
- Watchlist - Domains to monitor
This feature is under development.
Pricing Manager Coming Soon
Domain pricing management
domain pricing management
Configure and manage domain pricing:
- Base Pricing - Default TLD prices
- Premium Pricing - Special domain rates
- Tiered Pricing - Volume discounts
- Renewal Pricing - Annual renewal rates
- Transfer Pricing - Domain transfer fees
This feature is under development.
Deals Manager Coming Soon
Domain deals & promotions
Domain Deals & Promotions
Manage special offers and promotions:
- Flash Sales - Limited time offers
- Bundle Deals - Multi-domain packages
- Coupon Codes - Discount codes
- Seasonal Promotions - Holiday specials
- New User Deals - First-time buyer discounts
This feature is under development.
Policy Manager Coming Soon
Domain policy management
Domain Policy Management
Configure domain registration and usage policies:
- Registration Rules - Who can register which TLDs
- Content Policies - Acceptable use guidelines
- Dispute Resolution - Trademark and ownership policies
- Compliance - ICANN and legal requirements
- Abuse Prevention - Anti-spam and security policies
This feature is under development.
Shopnet.Domains Control Panel Connected
Domain store client control panel
Client Endpoint
Data Source
📊 Sync Status Read-Only
Note: Sync status is managed on the client (shopnet.domains → WP Admin → Data Sync). This panel shows read-only status for reference.
🚀 Push Data to Client
Trigger a webhook push to send current database state to shopnet.domains. This will update all TLDs and categories matching the filters below.
Requires webhook to be configured on client📜 Sync History
Loading sync history...
🔍 Data Filters
Control which portions of the database are shared with this client endpoint.
Select which TLD groups will be pushed to this client.
Filter by tld_owner field. Database field: tld_owner VARCHAR(255)
Filter by is_public field. Public = visible to customers.
Currently syncs all categories to the client.
🔗 Webhook Configuration Placeholder
Secret must match the one configured in shopnet.domains WP Admin → Data Sync.
📋 Client-Side Controls Reference (shopnet.domains)
Settings managed in WordPress Admin → Domain Store → Data Sync, or hardcoded in theme files.
| Setting | Location | Status |
|---|---|---|
| Auto-Sync Enabled | WP Admin → Data Sync | Keep on Client |
| Sync Frequency | WP Admin → Data Sync | Keep on Client |
| Delete Orphans | WP Admin → Data Sync | Keep on Client |
| TLD Group Filter |
Now: Control Panel above |
Implemented |
| Category Filter |
Now: Control Panel above |
Implemented |
| Owner Filter | Control Panel above | Implemented |
| Webhook Secret | WP Admin → Data Sync | Must Match Both |
| Display Filter (ForSale) |
Theme: front-page.php, functions.php Filters WooCommerce product display |
Can Remove |
Note: The ForSale hardcoded filter in shopnet-domain-theme can now be removed since this control panel filters data at the source.
Files: front-page.php (lines 22-23, 31, 213-214, 239-240, 378-379, 443-444, 549-550), functions.php (lines 569-572).
🔮 Planned Features
- Real-time sync status monitoring via WebSocket
- Selective TLD push (instead of full database)
- Sync conflict resolution and rollback
- Client health check and connectivity monitoring
- Sync scheduling from this panel
Audit log of all push/pull operationsImplemented- Change-based sync (only sync modified records) Implemented
TLD Manager
Manage Top-Level Domains
Domain Sources
| ID | TLD | Text Root | Group | Description | |
|---|---|---|---|---|---|
| Loading... | |||||
Category Management
Manage TLD categories and groupings
CSV Import
Import TLDs from CSV files
Drop CSV file here or click to browse
Required columns: tld_punycode, tld_unicode, tld_group
Audit Log
Database change history
| Time | Action | Table | Record ID | User | Changes |
|---|---|---|---|---|---|
| Loading... | |||||
CSV Export
Export TLDs or Categories to CSV
1. Select Data Type
2. Filter Data (Optional)
3. Select Columns
4. Export
Loading preview...
Relevancy Scoring Tool
Calculate relevancy scores for TLDs by category
Calculate Relevancy Scores
Calculate how relevant each TLD is to a category based on keywords
Scoring Weights
SODI Scoring Tool
Shopnet Optimal Domain Indicator — evaluate domain SEO and AI search visibility
Shopnet Optimal Domain Indicator
Evaluate domain names for SEO performance and AI search visibility (GEO). Configure weights and scoring rules below.
SODI Parameter Weights
Test SODI Calculator
Score Ranges
TLD SODI Scores from Database
Preview SODI scores for TLDs using current weight settings. Use "Update All TLD Scores" to save to database.
SOPI Scoring
Shopnet Optimization & Performance Index — evaluate product quality and marketplace optimization
Shopnet Product Optimization Index
SOPI evaluates products across 8 dimensions: Rating Quality, Review Volume, Category Rank, Price Value, Data Completeness, Prime & Trust, Brand Strength, and Review Sentiment. Scores are pre-computed and stored in the database. Same 0-100 scale and color scheme as SODI.
SOPI Dimension Weights
Total: 100%Product SOPI Lookup
Score Ranges (same scale as SODI)
Top Products by SOPI Score
Products with the highest optimization scores from the database.
SOPI by Category
Average SOPI scores across product categories.
Average Dimension Scores (All Products)
My TLD List
No TLDs in your list yet
Search for TLDs and add them here
Bulk Actions
Data Remediation
Fix data quality issues
Fix Data Quality Issues
Review and fix data issues by type. Work through each issue category to improve data quality score.
Bulk Fix Options
Keywords Generator
Generate SEO keywords for TLDs or categories
Generate Keywords for TLDs or Categories
Generate relevant SEO keywords for TLDs or categories to improve searchability and relevancy scoring.
Descriptions Generator
Generate descriptions for TLDs or categories
Generate Descriptions for TLDs or Categories
Generate short and long descriptions for TLDs or categories to improve product pages and SEO.
API Key Management
Manage API keys and access credentials
| Name | Status | Permissions | Last Used | Usage | Actions |
|---|---|---|---|---|---|
| Loading... | |||||
Webhook Subscriptions
Manage webhook event subscriptions
| URL | Events | Secret | Created | Actions |
|---|---|---|---|---|
| Loading... | ||||
Test Webhook
Admin Client Internal
Domain search test environment
Admin Client Test Environment
This page provides a test environment for the Domain Finder Module used by the Data GUI for internal tasks. The Finder Module below mirrors the universal search component shared across all endpoints. The Client Endpoint Filters simulate how different client configurations filter search results before delivery. Use this to test search behavior and endpoint filtering without affecting production data.
Client Endpoint Filters
These filters simulate client endpoint export filtering. Results pass through these filters before display.
Search Results
| ID | TLD | Punycode | Text Root | Group | Description |
|---|---|---|---|---|---|
| Click FIND to search TLDs | |||||
Domain Finder Module Config
Taxonomizer
"Find or Do Anything" — Taxonomy Validator
Simple Analysis
Enter a use case and the Taxonomizer will auto-break it into steps, mapping each step to Shopnet UID types.
The Taxonomizer validates the Shopnet taxonomy by breaking real-world use cases into steps and mapping each step to the 9 UID types (User, Thing, Location, Transaction, Payment, List, Network, Agent, Activity). It answers: can the taxonomy describe anything a person might want to find or do?
Agent Optimizer
Test, Compare & Optimize Agent Prompts
Module Admin V1-alpha
Manage the module registry and endpoint module installations
| Module ID | Name | Version | Config | Actions |
|---|---|---|---|---|
| Select an endpoint to view installed modules | ||||
| Module ID | Name | Brand | Version | Status | Plan | Actions |
|---|---|---|---|---|---|---|
| Loading registry... | ||||||
Tag Payload Preview
No preview loaded
System Registry
S0 Governance — Service Assemblies, Components & Edges
Loading service assemblies...
GUI Design
Standard header component reference and button color theme
Button Color Theme
Semantic color system — each color indicates a specific action type across the entire console.
Standard Header Component
| Class | Purpose |
|---|---|
.std-header | Main container — flex, space-between, gradient bg, purple bottom border |
.std-header__left | Icon + title area (flex, align-start) |
.std-header__icon | 40x40 purple gradient square with panel's sidebar SVG |
.std-header__title | h1 — panel title (1.5rem, weight 600) |
.std-header__subtitle | p — panel description (muted color, 0.9375rem) |
.std-header__version | Version badge span (inline with title) |
.std-header__toolbar | Right-side toolbar container (flex, gap 1rem) |
.std-header__action | Individual button + label column |
.std-header__action-label | Uppercase label under button (0.65rem) |
.std-header__action-time | Timestamp under label (0.6rem, for sync buttons) |
Header Variations
| Variation | Example Panels | Toolbar Content |
|---|---|---|
| Simple (no toolbar) | Network Map, Settings, Security | None |
| CRUD toolbar | Portals, Domains, Products | Add (green) + Edit (orange) + Remove (red) + Pulse (purple) |
| Full toolbar | Endpoint Registry | CRUD + Refresh + Configure + Export CSV |
| Sync with timestamps | Infrastructure | AWS Sync + Pulse Sync + CSV (with timestamps) |
| Version badge | Death Star, KPI Dashboard | .std-header__version span in title |
| Domain Store tools | TLD Manager, Categories | Panel-specific action buttons |
Content Design
Standard content component reference — stats, tables, toolbars, cards, buttons, badges
Stats Overview
Dashboard KPI cards — .std-stats grid with .std-stat cards. Color-coded icons, large values, trend indicators.
Data Table with Toolbar
Filter toolbar (.std-toolbar) with search, dropdowns, buttons — above a data table (.std-table).
| Name | URL | Status | Response | Last Checked | Actions |
|---|---|---|---|---|---|
| shopnet.network | https://shopnet.network | Active | 89ms | 2 min ago |
|
| data.shopnet.network | https://data.shopnet.network | Active | 124ms | 2 min ago |
|
| assist.shopnet.network | https://assist.shopnet.network | Warning | 342ms | 5 min ago |
|
| radius.shopnet.network | https://radius.shopnet.network | Error | — | 12 min ago |
|
| api.shopnet.network | https://api.shopnet.network | Active | 67ms | 1 min ago |
|
Action Cards
Clickable operation cards (.std-action-card) — for control panels like Radius, Pulse, Infrastructure.
Button Color Theme
Semantic color system — each color indicates a specific action type across the entire console.
Icon Buttons — .pulse-btn (headers & toolbars)
44x44 square icon buttons used in .std-header toolbars and inline table actions.
Text Buttons — .std-btn (content areas)
Labeled buttons with optional icons for use inside content sections, toolbars, and dialogs.
Badges
Status badges (.std-badge) for inline status indicators in tables, cards, and text.
Info Boxes
Contextual alerts (.std-info-box) — info, success, warning, error variants.
Empty State
Placeholder shown when a table or section has no data (.std-empty).
| Name | Status | Last Updated |
|---|---|---|
|
No results found
Try adjusting your search or filter criteria.
|
||
Component Reference
| Component | CSS Class | Purpose |
|---|---|---|
| Section | .std-section | Content area wrapper with padding |
| .std-section__title | h2 section heading with icon + bottom border | |
| .std-section__subtitle | Muted description under section title | |
| Stats | .std-stats | Responsive grid for stat cards |
| .std-stat | Individual stat card (icon + value + label + trend) | |
| .std-stat__icon--{color} | purple, green, blue, orange, red icon backgrounds | |
| Table | .std-table-wrap | Table container with border and radius |
| .std-table | Data table with sticky header and hover rows | |
| .std-table-wrap--scroll | Scrollable variant (max-height: 400px) | |
| Toolbar | .std-toolbar | Filter/action bar above tables |
| .std-search | Search input with icon | |
| .std-select | Styled dropdown select | |
| Buttons | .std-btn | Text button with icon + label |
| .std-btn--{variant} | primary, secondary, green, orange, red, sm | |
| Actions | .std-actions | Grid for clickable action cards |
| .std-action-card | Clickable card with icon, title, description | |
| .std-action-card--danger | Red border variant for destructive actions | |
| Info Box | .std-info-box | Contextual alert with icon |
| .std-info-box--{variant} | info (blue), success (green), warning (orange), error (red) | |
| Badge | .std-badge | Inline status pill badge |
| .std-badge--{color} | green, red, orange, blue, purple, gray | |
| Empty | .std-empty | Empty state placeholder (icon + title + text + button) |
| Pagination | .std-pagination | Table pagination with info + page buttons |
Card Design v1.0 Design Guide
Taxonomy card system — auto-generated cards from RDS and static card patterns
Style Guide Section 25 | February 8, 2026
1. Automatic Endpoint Cards
Cards auto-generated from endpoint_taxonomy in RDS via Connect Gateway API. Used on all SHOPNET.NETWORK endpoint tabs.
Data Flow Architecture
API Endpoint & Filters
GET /api/v1/sites/cards?endpoint_type=W&website_purpose=brochure&limit=200
| Parameter | Values | Description |
|---|---|---|
endpoint_type | W A D N | Website, Agent Engine, Database, Node |
website_purpose | brochure product_store domain_store portal console other | Purpose filter (websites only) |
platform_type | CO CP WP WW SH RA L3 W3G | Infrastructure platform |
limit | number | Max results (default 200) |
Section Sub-Header
Every card section renders this bar above the card grid. The counter and status dot update dynamically from Pulse data.
Example Section (12)
12 endpoints (11 online) auto generated cards THE LAW - RDS| Element | CSS Class | Content |
|---|---|---|
| Icon | .section-icon | Emoji per tab config |
| Title | h3 | Section name + (count) |
| Counter | .section-status | Dot + "{n} endpoints ({n} online)" |
| Origin badge | .section-badge (muted) | "auto generated cards" |
| Source badge | .section-badge | "THE LAW - RDS" (blue pill) |
Card Anatomy — Live Example
Each card is rendered by renderNetworkCard(data). Click opens detail modal. External link (↗) opens domain in new tab.
Status Dot Logic
The status dot combines taxonomy_status (from RDS) with live_status (from Pulse Monitor). Live sites get real-time overlay.
| taxonomy_status | pulse_status | Dot | Footer Text |
|---|---|---|---|
planned |
— | Grey | Placeholder |
wip |
— | Orange | Building |
live |
online |
Green | online |
live |
degraded |
Orange | degraded |
live |
offline |
Red | offline |
live |
null |
Grey | checking |
Badge Color Map
Taxonomy code pills from THE LAW. Tooltips populated from TAXONOMY_LABELS (loaded from taxonomy_definition table).
Endpoint Type
Platform Type
Managed By
Card Grid & CSS Reference
| Class | CSS | Purpose |
|---|---|---|
.card-grid | grid; repeat(auto-fill, minmax(280px, 1fr)); gap: 1rem | Responsive grid container |
.unified-card | bg-primary; radius-lg; 1rem pad; 160px min-h; 1px border | Base card box |
.network-card | extends .unified-card | Taxonomy-specific card variant |
.card-header | flex; gap 8px; mb 8px | Status dot + UID badge row |
.card-id-badge | SF Mono; 0.7rem; #e0f2fe bg; #0369a1 text | Monospace UID pill |
.card-title | 0.95rem; 600 weight; ellipsis overflow | Domain name / label |
.card-badges | flex; gap 4px; wrap | Taxonomy code pills |
.card-badge | 0.65rem; 600 weight; white text; colored bg | Individual taxonomy pill |
.card-description | 0.8rem; 2-line clamp; flex-grow | Notes text |
.card-footer | flex; space-between; border-top; 0.7rem | Date + status text |
.card-link | absolute; top-right; 28px circle; primary bg | External link button |
Responsive: ≥1200px → minmax(320px, 1fr) | ≤768px → single column
Tabs Using Automatic Endpoint Cards
Each tab calls loadEndpointCards(config) with specific filters. All share the same renderer and card CSS.
| Tab | Icon | endpoint_type | website_purpose | platform_type | JS Function |
|---|---|---|---|---|---|
| Portal Sites | 🚪 | W | portal | — | loadPortals() |
| Domain Stores | 🌐 | W | domain_store | — | loadDomainStores() |
| Product Stores | 🛒 | W | product_store | — | loadProductStores() |
| Brochure (On Demand) | ⚡ | W | brochure | — | loadBrochureLambda() |
| Brochure (Persistent) | 🔄 | W | brochure | RA | loadBrochureRadius() |
| Web3 Sites | 🌐 | W | other | — | loadWeb3Sites() |
| Web3 Gateways | 🔗 | N | — | W3G | loadWeb3Gateways() |
| AI Agents | 🤖 | A | — | — | loadAgents() |
| Files & Data Sources | 💾 | D | — | — | loadDatabases() |
| Network Nodes | 🔗 | N | — | excl. W3G | loadNetworkNodes() |
2. Static Cards
Hardcoded cards for fixed-content panels — team cards, action cards, service cards, and other non-endpoint card types.
cards.shopnet v1.0 Card System
The Deathstar Card System — Universal Card Architecture
Architecture Guide | February 8, 2026 | 3 Classes • 13 Card Types • 5 Live • 3 Proposed • 5 Future
Vision
Cards are the universal UI primitive for the Deathstar. Every entity, metric, task, and action in the system is represented as a card. The card system is not just a display pattern — it is the primary interaction model for the entire console.
Three classes of card, each serving a fundamentally different purpose: Entity Cards (things that exist), Visualization Cards (data and metrics), and Operational Cards (work and actions).
Class A: Entity Cards UID-Based
Every entity card maps 1:1 to a UID namespace and a source-of-truth table in RDS. The card is a presentation layer over the entity — never the other way around.
| # | Card Type | UID Prefix | Source Table | Database | Renderer | Status |
|---|---|---|---|---|---|---|
| A1 | Endpoint Card | sn_ | endpoint_taxonomy | shopnet_sites | loadEndpointCards() | LIVE |
| A2 | Agent Card | sa_ | agents | shopnet_assist | loadAssistOverview() | LIVE |
| A3 | Module Card | sm_ | module_taxonomy | shopnet_sites | loadModuleCards() | PROPOSED |
| A4 | User Card | su_ | user_taxonomy | shopnet_crm | TBD | DESIGNED |
| A5 | List Card | sl_ | list_taxonomy | shopnet_registry | TBD | DESIGNED |
| A6 | Transaction Card | sp_ | TBD | shopnet_payments | TBD | FUTURE |
| A7 | Product Card | TBD | TBD | TBD | TBD | FUTURE |
| A8 | Domain Card | sn_ | endpoint_taxonomy | shopnet_sites | loadEndpointCards() | FUTURE |
Class B: Visualization Cards KPI Module
Data visualizations powered by Chart.js on GridStack drag-and-drop grids. Already implemented in the KPI Dashboard Module with 9 visualization types, 4-tab card wizard, metric registry, and per-user dashboard persistence.
| # | Visualization Type | Library | Grid Size | Use Case |
|---|---|---|---|---|
| B1 | Stat Card | Custom HTML | 3×2 | Big number + trend arrow |
| B2 | Line Chart | Chart.js | 6×3 | Time series (traffic, performance) |
| B3 | Bar Chart | Chart.js | 4×3 | Comparisons (build counts) |
| B4 | Pie Chart | Chart.js | 3×3 | Distribution (endpoint types) |
| B5 | Doughnut | Chart.js | 3×3 | Distribution with center value |
| B6 | Gauge | Chart.js | 3×2 | Meters and percentages |
| B7 | Radar | Chart.js | 4×4 | Multi-axis comparison |
| B8 | Data Table | Custom HTML | 6×3 | Tabular data display |
| B9 | Horizontal Bar | Chart.js | 4×3 | Labeled comparisons |
Class C: Operational Cards Work & Actions
Cards that represent work items, actions, and ad hoc content.
| # | Card Type | Purpose | Data Source | Status |
|---|---|---|---|---|
| C1 | Roadmap Card | Jira-style work items (Epic/Feature/Task/Bug) | roadmap_cards | PROPOSED |
| C2 | Action Card | Operational buttons triggering wizards/modals | Static HTML | LIVE |
| C3 | Panel Stat Card | Simple KPI counters in operational panels | Mixed | LIVE |
| C4 | Static Card | Wizard-managed ad hoc items | console_cards | PROPOSED |
Database Architecture shopnet_sites
Card type definitions stored in taxonomy_definition (existing table). Three new tables needed for Phases 1–2.
| Table | Database | Phase | Purpose | Status |
|---|---|---|---|---|
taxonomy_definition | shopnet_sites | P0 | Card type codes (22 rows) + website_purpose values (5 rows) | EXISTS |
endpoint_taxonomy | shopnet_sites | P0 | 17 static cards migrating to endpoint rows | EXISTS |
module_taxonomy | shopnet_sites | P1 | GitHub repos, templates, libraries (7 seed rows) | NEW |
console_cards | shopnet_sites | P1 | Wizard-managed ad hoc cards (2 seed rows) | NEW |
roadmap_cards | shopnet_sites | P2 | Jira-style Kanban work items | NEW |
card_type_config | shopnet_sites | P3 | Rich metadata per card type (renderer, CSS, API) | FUTURE |
Implementation Phases
| Phase | Scope | Effort | Impact | New Tables |
|---|---|---|---|---|
| P0 | Migrate 17 static cards → endpoint_taxonomy rows | LOW | HIGH | None (data only) |
| P1a | Module Cards — table + API + renderer | MEDIUM | MEDIUM | module_taxonomy |
| P1b | Static Cards + Radius wizard (Add/Edit/Delete Card) | MEDIUM | MEDIUM | console_cards |
| P2a | .std-card CSS unification across all entity cards | MEDIUM | HIGH | None (CSS only) |
| P2b | Roadmap Kanban — table + board UI + drag-and-drop | HIGH | HIGH | roadmap_cards |
| P3+ | User/List/Transaction/Product cards as SND databases built | MEDIUM each | Incremental | Per entity |
Radius Card Wizards Phase 1b
Three wizards on the Radius Control Panel for managing console cards stored in the console_cards table. These enable non-developer card management via UI.
Add Card Wizard
Select target panel and section, fill title, description, icon, external link, badge, and status. Connect Gateway issues SC- card_uid.
Change Card Wizard
Select existing card from dropdown. Edit any field except card_uid (immutable). Saves to console_cards table via API.
Delete Card Wizard
Select card, review details, double-confirm deletion. Removes from console_cards table. card_uid never reused.
Design Principles
Cards are views, not data. The card is always a presentation layer over a source-of-truth table.
One UID, one card. Every entity card maps to exactly one UID namespace.
The Law governs. Connect Gateway is the sole authority for issuing UIDs.
Automate by default. Static/hardcoded cards are a last resort.
Class separation. Entity, Visualization, and Operational cards are three separate systems.
Jira patterns for roadmap. Three immutable status categories. Kanban drag-and-drop. Epic hierarchy.