anonpenguin23 bcfb2b7868 fix(gateway): give namespace gateways the API-key HMAC secret
Namespace gateways never received the API-key HMAC secret, so
auth.Service.HashAPIKey returned keys UNCHANGED (service.go:172). One gap,
two symptoms — both confirmed live on devnet:

1. A namespace gateway could not authenticate ANY key from the authoritative
   core registry: core stores 64-char HMAC-SHA256 hashes, the namespace
   gateway looked up the 39-char raw key. Valid key on main gateway :6001 =>
   200, same key on namespace gateway :10004 => 401. This is what broke
   serverless WASM http_fetch calls to /v1/auth/token (bugboard #160).
2. Keys the namespace gateway wrote were stored in PLAINTEXT, against
   docs/SECURITY.md:54-59. The anchat-test namespace RQLite holds 361
   39-char plaintext keys vs 64-char hashes in core.

The main gateway reads the secret from <oramaDir>/secrets/api-key-hmac-secret
(node/gateway.go:50). The namespace spawner never passed it and the gateway
YAML had no field for it, so it could not have been passed at all.

- cmd/gateway/config.go: new api_key_hmac_secret YAML field
- namespace/systemd_spawner.go: read the same secret file at spawn and emit
  it; a missing or blank secret now fails the spawn loudly rather than
  booting a gateway that cannot authenticate anything
- config file mode pinned to 0600 by test (it already was)

Also reverts the API-key lookup change from 0.122.97. That change pointed
namespace gateways at their own RQLite, which split the system into two
disagreeing key registries and caused the internal 401s above. apiKeyDB()
now resolves authClient (global) -> client, never sqlDB. GlobalRQLiteDSN's
"API key validation" comment was correct: keys live in the core registry.

Verified on devnet 0.122.99 across both gateways and all nodes: external
200, internal namespace gateway 200, bogus 401. Full suite green.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-07-27 15:49:12 +03:00
2026-02-14 14:14:04 +02:00
2025-08-09 21:44:26 +03:00
2026-03-26 18:40:20 +02:00

Orama Network

A decentralized infrastructure platform combining distributed SQL, IPFS storage, caching, serverless WASM execution, and privacy relay — all managed through a unified API gateway.

Packages

Package Language Description
core/ Go API gateway, distributed node, CLI, and client SDK
sdk/ TypeScript @debros/orama — JavaScript/TypeScript SDK (npm)
website/ TypeScript Marketing website and invest portal
vault/ Zig Distributed secrets vault (Shamir's Secret Sharing)
os/ Go + Buildroot OramaOS — hardened minimal Linux for network nodes

Quick Start

# Build the core network binaries
make core-build

# Run tests
make core-test

# Start website dev server
make website-dev

# Build vault
make vault-build

Documentation

Document Description
Architecture System architecture and design patterns
Deployment Guide Deploy apps, databases, and domains
Dev & Deploy Building, deploying to VPS, rolling upgrades
Security Security hardening and threat model
Monitoring Cluster health monitoring
Client SDK Go SDK documentation
Serverless WASM serverless functions
Common Problems Troubleshooting known issues

Contributing

See CONTRIBUTING.md for setup, development, and PR guidelines.

License

AGPL-3.0

Description
A robust, decentralized peer-to-peer network built in Go, providing distributed SQL database, key-value storage, pub/sub messaging, and resilient peer management. Designed for applications needing reliable, scalable, and secure data sharing without centralized infrastructure.
https://orama.network
Readme AGPL-3.0 2.7 GiB
Languages
Go 78.9%
TypeScript 12.6%
Zig 3.7%
MDX 3.4%
PLpgSQL 0.7%
Other 0.6%