Skip to content

Tenets

These are our non-negotiable engineering principles, listed in priority order. When two tenets conflict, the higher-ranked tenet wins.

1. Digital Sovereignty

Users own their data. Period.

  • Every data type supports export in standard formats (JSON, CSV)
  • Every data type supports deletion (GDPR right to erasure)
  • No vendor lock-in — not to Firebase, not to AWS, not to us
  • The StorageAdapter interface exists specifically to guarantee this
  • Data portability is a feature, not an afterthought

In practice: If a design decision makes it harder for users to leave the platform, we reject it.

2. Storage Agnosticism

No service ever imports a storage backend directly.

  • All data operations flow through the StorageAdapter interface
  • Domain services (SharedDataService, PermissionService, etc.) receive IDataLayerService via dependency injection
  • The only package that knows about Firebase is @cyber-eco/firebase
  • @cyber-eco/services has zero imports from any firebase/* module

In practice: You should be able to grep -r "firebase" packages/services/ and get zero results.

3. Privacy by Default

Permissions are checked on every operation, not assumed.

  • The DataLayerService orchestrator checks permissions before every read and write
  • No "open" collections — every Firestore collection has security rules
  • Minimum data principle: APIs return only what the requester is authorized to see
  • GDPR compliance is built into the architecture (consent tracking, data export, deletion)
  • Audit logging for permission changes

In practice: If you add a new API endpoint and forget to add permission checks, the DataLayerService will deny the request by default.

4. Wellbeing by Design

Technology should enhance human life, not consume it.

  • APIs default to paginated responses — no unbounded data dumps
  • Cache reduces load on both infrastructure and users' devices
  • Notification deduplication — one alert, not thirty
  • Rate limiting protects both the system and the user from abuse
  • No dark patterns in data access (e.g., no "engagement optimization" queries)

In practice: If a feature would make the platform more addictive rather than more useful, we don't build it.

5. Offline-First Ready

The data layer assumes intermittent connectivity.

  • Multi-level cache (L1 in-memory + L2 optional) provides fast reads even when offline
  • SyncService handles conflict resolution when reconnecting
  • FirebaseStorageAdapter supports IndexedDB persistence
  • All interfaces include both synchronous cache reads and async remote fetches

In practice: A user on a spotty mobile connection should still be able to view their groups, see recent expenses, and draft new transactions.

6. Community-Driven Evolution

The ecosystem grows through collaboration, not gatekeeping.

  • Open source packages that anyone can install and inspect
  • Modular architecture — contribute a new StorageAdapter, a new domain service, or a new set of types without touching existing code
  • Comprehensive documentation and examples
  • Semantic versioning with clear changelogs
  • Contribution guidelines and code of conduct

In practice: A developer outside the core team should be able to build a CyberEco-compatible app using only the published packages and documentation.

7. Simplicity Over Cleverness

Every abstraction must earn its place.

  • Don't abstract until you have at least two concrete use cases
  • Prefer explicit code over magic (no decorators, no reflection, no metaprogramming)
  • One way to do things, not three
  • If a utility function is only used once, inline it
  • Comments explain "why", not "what"

In practice: Before adding a new abstraction layer, ask: "What concrete problem does this solve today?" If the answer is "it might be useful someday," don't build it.