Files
mleku 59247400dc
Some checks failed
Go / build-and-release (push) Has been cancelled
Remove Dgraph support from the codebase.
Dgraph-related functionality, configuration, and benchmarks have been removed from the project. This streamlines the codebase to focus on supported backends, specifically eliminating Dgraph references in favor of Neo4j and other implementations. Version bumped to reflect the changes.
2025-12-03 19:33:37 +00:00
..
2025-11-23 08:15:06 +00:00
2025-11-23 08:15:06 +00:00
2025-11-23 08:15:06 +00:00
2025-12-03 12:59:23 +00:00
2025-11-23 08:15:06 +00:00
2025-11-23 08:15:06 +00:00

Neo4j Database Backend

A graph database backend implementation for the ORLY Nostr relay using Neo4j.

Quick Start

1. Start Neo4j

docker run -d --name neo4j \
  -p 7474:7474 -p 7687:7687 \
  -e NEO4J_AUTH=neo4j/password \
  neo4j:5.15

2. Configure Environment

All Neo4j configuration is defined in app/config/config.go and visible via ./orly help:

export ORLY_DB_TYPE=neo4j
export ORLY_NEO4J_URI=bolt://localhost:7687
export ORLY_NEO4J_USER=neo4j
export ORLY_NEO4J_PASSWORD=password

Note: Configuration is centralized in app/config/config.go. Do not use os.Getenv() directly in package code - all environment variables should be passed via the database.DatabaseConfig struct.

3. Run ORLY

./orly

Features

  • Graph-Native Storage: Events, authors, and tags stored as nodes and relationships
  • Efficient Queries: Leverages Neo4j's native graph traversal for tag and social graph queries
  • Cypher Query Language: Powerful, expressive query language for complex filters
  • Automatic Indexing: Unique constraints and indexes for optimal performance
  • Relationship Queries: Native support for event references, mentions, and tags
  • Web of Trust (WoT) Extensions: Optional support for trust metrics, social graph analysis, and content filtering (see WOT_SPEC.md)

Architecture

See docs/NEO4J_BACKEND.md for comprehensive documentation on:

  • Graph schema design
  • How Nostr REQ messages are implemented in Cypher
  • Performance tuning
  • Development guide
  • Comparison with other backends

Web of Trust (WoT) Extensions

This package includes schema support for Web of Trust trust metrics computation:

  • WOT_SPEC.md - Complete specification of the WoT data model, based on the Brainstorm prototype

    • NostrUser nodes with trust metrics (influence, PageRank, verified counts)
    • NostrUserWotMetricsCard nodes for personalized multi-tenant metrics
    • Social graph relationships (FOLLOWS, MUTES, REPORTS)
    • Cypher schema definitions and example queries
  • ADDITIONAL_REQUIREMENTS.md - Implementation requirements and missing details

    • Algorithm implementations (GrapeRank, Personalized PageRank)
    • Event processing logic for kinds 0, 3, 1984, 10000
    • Multi-tenant architecture and configuration
    • Performance considerations and deployment modes

Note: The WoT schema is applied automatically but WoT features are not yet fully implemented. See ADDITIONAL_REQUIREMENTS.md for the roadmap.

File Structure

Core Implementation

  • neo4j.go - Main database implementation
  • schema.go - Graph schema and index definitions (includes WoT extensions)
  • query-events.go - REQ filter to Cypher translation
  • save-event.go - Event storage with relationship creation
  • fetch-event.go - Event retrieval by serial/ID
  • serial.go - Serial number management
  • markers.go - Metadata key-value storage
  • identity.go - Relay identity management
  • delete.go - Event deletion (NIP-09)
  • subscriptions.go - Subscription management
  • nip43.go - Invite-based ACL (NIP-43)
  • import-export.go - Event import/export
  • logger.go - Logging infrastructure

Documentation

  • README.md - This file
  • WOT_SPEC.md - Web of Trust data model specification
  • ADDITIONAL_REQUIREMENTS.md - WoT implementation requirements and gaps
  • EVENT_PROCESSING_SPEC.md - Event-driven vertex management specification
  • IMPLEMENTATION_SUMMARY.md - Implementation overview and status
  • TESTING.md - Test guide and troubleshooting
  • The Brainstorm prototype_ Neo4j Data Model.html - Original Brainstorm specification document

Tests

  • social-event-processor_test.go - Comprehensive tests for kinds 0, 3, 1984, 10000

Testing

Quick Start

# Start Neo4j using docker-compose
cd pkg/neo4j
docker-compose up -d

# Wait for Neo4j to be ready (~30 seconds)
docker-compose logs -f neo4j  # Look for "Started."

# Set Neo4j connection
export ORLY_NEO4J_URI="bolt://localhost:7687"
export ORLY_NEO4J_USER="neo4j"
export ORLY_NEO4J_PASSWORD="testpass123"

# Run all tests
go test -v

# Run social event processor tests
go test -v -run TestSocialEventProcessor

# Cleanup
docker-compose down -v

Test Coverage

The social-event-processor_test.go file contains comprehensive tests for:

  • Kind 0: Profile metadata processing
  • Kind 3: Contact list creation and diff-based updates
  • Kind 1984: Report processing (multiple reports, different types)
  • Kind 10000: Mute list processing
  • Event traceability: Verifies all relationships link to source events
  • Graph state: Validates final graph matches expected state
  • Helper functions: Unit tests for diff computation and p-tag extraction

See TESTING.md for detailed test documentation, troubleshooting, and how to view the graph in Neo4j Browser.

Viewing Test Results

After running tests, explore the graph at http://localhost:7474:

// View all social relationships
MATCH path = (u1:NostrUser)-[r:FOLLOWS|MUTES|REPORTS]->(u2:NostrUser)
RETURN path

// View event processing history
MATCH (evt:ProcessedSocialEvent)
RETURN evt ORDER BY evt.created_at

Example Cypher Queries

Find all events by an author

MATCH (e:Event {pubkey: "abc123..."})
RETURN e
ORDER BY e.created_at DESC

Find events with specific tags

MATCH (e:Event)-[:TAGGED_WITH]->(t:Tag {type: "t", value: "bitcoin"})
RETURN e

Social graph query

MATCH (author:Author {pubkey: "abc123..."})
<-[:AUTHORED_BY]-(e:Event)
-[:MENTIONS]->(mentioned:Author)
RETURN author, e, mentioned

Performance Tips

  1. Use Limits: Always include LIMIT in queries
  2. Index Usage: Ensure queries use indexed properties (id, kind, created_at)
  3. Parameterize: Use parameterized queries to enable query plan caching
  4. Monitor: Use EXPLAIN and PROFILE to analyze query performance

Limitations

  • Requires external Neo4j database (not embedded)
  • Higher memory usage compared to Badger
  • Metadata still uses Badger (markers, subscriptions)
  • More complex deployment than single-binary solutions

Why Neo4j for Nostr?

Nostr is inherently a social graph with heavy relationship queries:

  • Event references (e-tags) → Graph edges
  • Author mentions (p-tags) → Graph edges
  • Follow relationships → Graph structure
  • Thread traversal → Path queries

Neo4j excels at these patterns, making it a natural fit for relationship-heavy Nostr queries.

License

Same as ORLY relay project.