anonpenguin23 17b06d38e4 fix(gateway,serverless): libp2p mesh peer-port + system-trigger auth bypass
Two serious bugs found via cross-node behavior observation:

1. libp2p peer-discovery published wrong port
   PeerDiscovery's multiaddr was using the gateway's HTTP API port (e.g.
   10004), not the actual libp2p TCP port. Remote gateways dialed that
   port, hit the HTTP server, received 400, and failed the libp2p
   multistream handshake ("message did not have trailing newline").
   Result: cluster-wide cross-node libp2p mesh had 0 connected peers
   and cross-node pubsub silently dropped 100% of messages.

   The libp2p port is OS-assigned at startup (client.go uses
   /ip4/0.0.0.0/tcp/0). It's not anywhere in cfg — it's only on
   host.Addrs(). Fix: drop the listenPort field from PeerDiscovery
   entirely and derive the port live from host.Addrs() via
   extractLibp2pTCPPort. WG IP still comes from getWireGuardIP
   (libp2p filters its own enumeration so WG IPs don't appear in
   host.Addrs(), but the listener is bound 0.0.0.0 so the port is
   reachable on the WG interface).

2. System triggers silently blocked by CanInvoke (#264)
   Cron, pubsub, database, timer, and job triggers all fire from
   gateway-internal state with no caller identity. Invoke() ran every
   request through CanInvoke(callerWallet) which returned false for
   the empty wallet — every fire returned ErrUnauthorized. Reported as
   a cron firing every minute with "unauthorized" for 19+ hours.

   Auth boundary for system triggers belongs at REGISTRATION time
   (POST /v1/functions/{name}/triggers, deploy-time auto-register
   from function.yaml). Skip the per-invocation check for system
   trigger types; user-driven triggers (HTTP, WebSocket) still gate
   on caller identity as before.

Tests:
- gateway/peer_discovery_test.go covers extractLibp2pTCPPort.
- serverless/invoke_system_trigger_test.go covers the bypass and the
  user-trigger gate.

VERSION bumped to 0.122.25.
2026-05-16 15:43:18 +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
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 1.6 GiB
Languages
Go 77.9%
TypeScript 13.1%
Zig 3.9%
MDX 3.6%
PLpgSQL 0.7%
Other 0.7%