DEV Community: Trinmar Boado

# Talaan Chain System 🔗

Trinmar Boado — Sun, 19 Oct 2025 14:57:40 +0000

Lightweight, tamperproof audit logging without blockchain complexity

Talaan Chain provides cryptographically-secured audit trails using hash chaining, distributed validation, and JWT signatures. It's designed for organizations that need blockchain-level integrity without the overhead.

The Problem with Blockchain for Internal Auditing

Blockchain is powerful but impractical for most organizational use cases:

graph TB
    subgraph "Blockchain Challenges"
        B1[High Infrastructure Cost<br/>$50K-500K+ annually]
        B2[Slow Performance<br/>3-15 transactions/sec]
        B3[Complex Setup<br/>6-12 months]
        B4[Specialized Skills<br/>Blockchain developers]
        B5[Public by Design<br/>Limited privacy control]
    end

    subgraph "What Organizations Actually Need"
        N1[Tamperproof Logs]
        N2[Reasonable Cost]
        N3[Fast Performance]
        N4[Simple Integration]
        N5[Private & Controlled]
    end

    B1 -.->|Mismatch| N2
    B2 -.->|Mismatch| N3
    B3 -.->|Mismatch| N4
    B4 -.->|Mismatch| N4
    B5 -.->|Mismatch| N5

    style B1 fill:#E74C3C
    style B2 fill:#E74C3C
    style B3 fill:#E74C3C
    style B4 fill:#E74C3C
    style B5 fill:#E74C3C
    style N1 fill:#50C878
    style N2 fill:#50C878
    style N3 fill:#50C878
    style N4 fill:#50C878
    style N5 fill:#50C878

The Reality: Most organizations don't need a global, decentralized ledger. They need provable audit trails in a controlled environment.

Why Talaan Chain?

1. Practical Tamperproofing

Instead of expensive cryptographic hashing (SHA-256), we use FNV-1a with multiple security layers:

graph TB
    subgraph "Defense in Depth"
        L1[Layer 1: Hash Chaining<br/>FNV-1a + Parent Reference]
        L2[Layer 2: Cryptographic Signatures<br/>JWT with Secret Key]
        L3[Layer 3: Distributed Validation<br/>Independent Mirror Servers]
    end

    subgraph "Attack Requirements"
        A1[Modify local database]
        A2[Recompute entire chain]
        A3[Forge JWT signature]
        A4[Compromise ALL mirrors]
        A5[Do it SIMULTANEOUSLY]
    end

    L1 --> A1 & A2
    L2 --> A3
    L3 --> A4 & A5

    Result[Practically Impossible<br/>for Internal Threats]

    A1 & A2 & A3 & A4 & A5 --> Result

    style L1 fill:#4A90E2
    style L2 fill:#50C878
    style L3 fill:#9B59B6
    style Result fill:#F39C12

Why This Works:

The combination of hash chaining + cryptographic signatures + distributed validation makes tampering extremely difficult in controlled environments. You'd need to:

Break the chain: Modify entry → recompute all downstream hashes
Forge signatures: Create valid JWT without secret key
Synchronize attack: Compromise 3+ independent servers simultaneously
Avoid detection: Complete within 15-second validation window

This is practically impossible for insider threats (the real risk in most organizations).

2. 10x Faster, 90% Cheaper

graph LR
    subgraph "Blockchain"
        BC1[SHA-256 Hashing<br/>~0.50ms per operation]
        BC2[Consensus Protocol<br/>Network overhead]
        BC3[Node Infrastructure<br/>$50K+ annual cost]
    end

    subgraph "Talaan Chain"
        TC1[FNV-1a Hashing<br/>~0.05ms per operation]
        TC2[No Consensus<br/>Direct validation]
        TC3[Standard Database<br/>$2-5K annual cost]
    end

    BC1 -.->|10x slower| TC1
    BC2 -.->|Network delay| TC2
    BC3 -.->|25x costlier| TC3

    style BC1 fill:#E74C3C
    style BC2 fill:#E74C3C
    style BC3 fill:#E74C3C
    style TC1 fill:#50C878
    style TC2 fill:#50C878
    style TC3 fill:#50C878

Performance Comparison:

Metric	Blockchain	Talaan Chain
Hash Speed	0.50ms (SHA-256)	0.05ms (FNV-1a)
Throughput	3-15 TPS	150+ TPS
Setup Time	6-12 months	2-3 days
Infrastructure	Specialized nodes	Standard database
Annual Cost	$50K-500K+	$2-10K

3. Simple Integration

Talaan Chain works with your existing database through standard triggers:

sequenceDiagram
    participant DB as Your Database
    participant Talaan as Talaan Chain
    participant Mirror as Mirror Server

    DB->>Talaan: Record Created/Updated/Deleted
    Note over Talaan: Generate hash<br/>Sign with JWT
    Talaan->>Talaan: Store in chain
    Talaan->>Mirror: Sync to mirrors
    Mirror-->>Talaan: Validated

    Note over DB,Mirror: Zero changes to your app code!

No code changes required. Install flows, configure triggers, done.

Compare to blockchain:

Rewrite data layer
Implement blockchain APIs
Manage wallet keys
Handle consensus logic

4. Distributed Validation Without Decentralization

You don't need a global network. You need trustworthy validators:

graph TB
    subgraph "Your Organization"
        Primary[(Primary Database<br/>Your Server)]
    end

    subgraph "Independent Validators"
        Mirror1[(Audit Department<br/>Separate Network)]
        Mirror2[(External Auditor<br/>Different Organization)]
        Mirror3[(Regulatory Body<br/>Government Server)]
    end

    Primary -->|Real-time Sync| Mirror1
    Primary -->|Real-time Sync| Mirror2
    Primary -->|Real-time Sync| Mirror3

    Mirror1 -.->|Cross-Validate| Mirror2
    Mirror2 -.->|Cross-Validate| Mirror3
    Mirror3 -.->|Cross-Validate| Mirror1

    Attacker[Internal Bad Actor] -.->|Attempts Tampering| Primary
    Primary -.->|Mismatch Detected| Alert[🚨 Automatic Alert]
    Mirror1 -.->|Validates Against| Alert
    Mirror2 -.->|Validates Against| Alert
    Mirror3 -.->|Validates Against| Alert

    style Primary fill:#4A90E2
    style Mirror1 fill:#50C878
    style Mirror2 fill:#50C878
    style Mirror3 fill:#50C878
    style Attacker fill:#E74C3C
    style Alert fill:#F39C12

Key Insight: In controlled environments (organizations, governments), you have trusted parties who can run independent validators. You don't need anonymous global consensus.

How It Works

Hash Chaining Explained

graph LR
    subgraph "Entry 1 (Genesis)"
        E1["parent_hash: 'genesis'<br/>payload: data<br/>current_hash: abc123"]
    end

    subgraph "Entry 2"
        E2["parent_hash: abc123<br/>payload: data<br/>current_hash: def456"]
    end

    subgraph "Entry 3"
        E3["parent_hash: def456<br/>payload: data<br/>current_hash: ghi789"]
    end

    E1 -->|Hash includes parent| E2
    E2 -->|Hash includes parent| E3

    Tamper["Try to modify Entry 2"] -.->|Changes hash| E2
    E2 -.->|Breaks chain| E3
    E3 -.->|Validation fails| Detected["Tampering Detected ⚠️"]

    style E1 fill:#50C878
    style E2 fill:#4A90E2
    style E3 fill:#9B59B6
    style Tamper fill:#E74C3C
    style Detected fill:#F39C12

Each entry includes:

Hash of its own payload (data)
Hash of previous entry (parent_hash)
Combined into current_hash

To tamper successfully, attacker must:

Recompute current entry hash
Recompute ALL subsequent entry hashes
Update all mirrors simultaneously
Complete before next validation cycle (15 seconds)

FNV-1a: Fast Enough for Security?

Question: "Isn't FNV-1a a non-cryptographic hash? Can't it be broken?"

Answer: Yes, it's non-cryptographic. But that's not the weakness you think it is.

graph TB
    subgraph "What Makes Blockchain Secure?"
        BC1[Cryptographic Hash<br/>SHA-256]
        BC2[Global Network]
        BC3[Proof of Work]
        BC4[Economic Incentives]
    end

    subgraph "What Makes Talaan Secure?"
        TC1[Fast Hash<br/>FNV-1a]
        TC2[Hash Chaining]
        TC3[Distributed Validators]
        TC4[JWT Signatures]
        TC5[Access Control]
    end

    BC1 -.->|Needed because| BC2
    BC2 -.->|Requires| BC3
    BC3 -.->|Sustained by| BC4

    TC1 -->|Combined with| TC2
    TC2 -->|Combined with| TC3
    TC3 -->|Combined with| TC4
    TC4 -->|Combined with| TC5

    Result1[Secure against<br/>Anonymous Attackers]
    Result2[Secure against<br/>Internal Threats]

    BC1 & BC2 & BC3 & BC4 --> Result1
    TC1 & TC2 & TC3 & TC4 & TC5 --> Result2

    style BC1 fill:#E74C3C
    style Result1 fill:#9B59B6
    style TC5 fill:#50C878
    style Result2 fill:#50C878

Context Matters:

Blockchain: Faces anonymous attackers with unlimited computing power → needs cryptographic security
Talaan Chain: Faces internal threats with limited access → needs layered defense

The Real Security: It's not about hash strength alone. It's about:

Chain Dependency: Can't modify one entry without breaking all subsequent ones
Distributed Copies: Need to compromise multiple independent systems
Time Constraints: Must complete attack within validation window
Audit Trails: Every access attempt is logged

System Architecture

graph TB
    subgraph "Your Application Layer"
        APP[Web/Mobile App]
        API[REST API]
    end

    subgraph "Database Layer"
        DB[(Primary Database)]
        TRIGGER[Database Triggers]
    end

    subgraph "Talaan Chain Layer"
        LOGGER[Chain Logger<br/>Creates entries]
        STORAGE[(Chain Storage<br/>talaan_chain)]
        MONITOR[Chain Monitor<br/>Validates every 15s]
    end

    subgraph "Validation Layer"
        MIRROR1[(Mirror 1)]
        MIRROR2[(Mirror 2)]
        MIRROR3[(Mirror 3)]
        VALIDATOR[Item Validator<br/>Public API]
    end

    APP --> API
    API --> DB
    DB --> TRIGGER
    TRIGGER -.->|Auto-trigger| LOGGER
    LOGGER --> STORAGE
    LOGGER -.->|Webhook| MIRROR1 & MIRROR2 & MIRROR3
    STORAGE --> MONITOR
    MONITOR -.->|Validates| MIRROR1 & MIRROR2 & MIRROR3
    STORAGE -.->|Query| VALIDATOR

    style APP fill:#4A90E2
    style DB fill:#4A90E2
    style LOGGER fill:#50C878
    style STORAGE fill:#50C878
    style MONITOR fill:#F39C12
    style VALIDATOR fill:#9B59B6

Use Cases

1. Financial Transactions

Track every transaction with immutable audit trails:

sequenceDiagram
    participant User as User
    participant System as App
    participant Talaan as Talaan Chain
    participant Auditor as Auditor

    User->>System: Transfer $10,000
    System->>System: Process transaction
    System->>Talaan: Log transaction
    Note over Talaan: Hash + Chain + Sign
    Talaan->>Talaan: Store immutably
    Talaan-->>System: Confirmed
    System-->>User: Success

    Note over System: 6 months later...
    Auditor->>Talaan: Query transaction history
    Talaan->>Talaan: Validate chain
    Talaan-->>Auditor: ✅ Original: $10,000<br/>✅ No modifications<br/>✅ Hash verified

Prevents:

Unauthorized transaction modifications
Deleted audit logs
Backdated entries
"System error" excuses

2. Document Management

Prove document authenticity and track changes:

stateDiagram-v2
    [*] --> Draft: Document Created
    Draft --> Review: Submitted
    Review --> Approved: Manager Signs
    Approved --> Published: Released

    Draft --> Talaan1: ✅ Logged
    Review --> Talaan2: ✅ Logged
    Approved --> Talaan3: ✅ Logged
    Published --> Talaan4: ✅ Logged

    Approved --> Tamper: Attempt Modification
    Tamper --> Detected: Hash Mismatch
    Detected --> [*]: ❌ Rejected

    Published --> [*]

Enables:

Version history verification
Non-repudiation (can't deny signing)
Forgery detection
Complete change audit

3. Access Control Logs

Monitor and prove system access:

graph LR
    subgraph "Access Events"
        E1[Login]
        E2[Permission Change]
        E3[Data Export]
        E4[Admin Action]
    end

    subgraph "Talaan Chain"
        L1[✅ Logged]
        L2[✅ Chained]
        L3[✅ Validated]
    end

    subgraph "Security Benefits"
        B1[Detect Unauthorized Access]
        B2[Prove Compliance]
        B3[Forensic Investigation]
        B4[Non-Repudiation]
    end

    E1 & E2 & E3 & E4 --> L1
    L1 --> L2
    L2 --> L3
    L3 --> B1 & B2 & B3 & B4

    style L1 fill:#50C878
    style L2 fill:#50C878
    style L3 fill:#50C878

Technical Details

Core Components

graph TB
    subgraph "1. Chain Logger"
        L1[Triggered by DB events]
        L2[Reads parent entry]
        L3[Generates hash]
        L4[Signs with JWT]
        L5[Stores & syncs]
    end

    subgraph "2. Mirror Receiver"
        M1[Receives webhook]
        M2[Verifies JWT]
        M3[Validates hash]
        M4[Stores copy]
    end

    subgraph "3. Chain Monitor"
        C1[Runs every 15s]
        C2[Validates chain]
        C3[Checks mirrors]
        C4[Alerts on mismatch]
    end

    subgraph "4. Item Validator"
        V1[Public API]
        V2[Queries history]
        V3[Validates chain]
        V4[Returns proof]
    end

    L1 --> L2 --> L3 --> L4 --> L5
    M1 --> M2 --> M3 --> M4
    C1 --> C2 --> C3 --> C4
    V1 --> V2 --> V3 --> V4

    L5 -.->|Webhook| M1
    L5 -.->|Stores| C2
    C2 -.->|Validates| M4

    style L3 fill:#50C878
    style M3 fill:#50C878
    style C2 fill:#F39C12
    style V3 fill:#9B59B6

Hash Generation Algorithm

// 1. Deterministic serialization (sorted keys)
function serializeJson(obj) {
  return JSON.stringify(obj, (key, value) => {
    if (value && typeof value === 'object' && !Array.isArray(value)) {
      return Object.keys(value).sort().reduce((sorted, key) => {
        sorted[key] = value[key];
        return sorted;
      }, {});
    }
    return value;
  });
}

// 2. FNV-1a hashing (fast, deterministic)
function fnv1aHash(str) {
  let hash = 2166136261; // FNV offset basis
  for (let i = 0; i < str.length; i++) {
    hash ^= str.charCodeAt(i);
    hash = Math.imul(hash, 16777619); // FNV prime
  }
  return (hash >>> 0).toString(16).padStart(8, '0');
}

// 3. Chain entry hash
current_hash = fnv1aHash({
  parent: parent_hash,
  payload: fnv1aHash(payload)
})

Chain Entry Structure

interface ChainEntry {
  talaan_id: string;      // UUID
  parent_id: string;      // Previous entry's talaan_id
  parent_hash: string;    // Previous entry's current_hash
  current_hash: string;   // This entry's hash
  payload: {
    $trigger: {           // Event data
      event: string;
      collection: string;
      key: string;
      payload: object;
    };
    $accountability: {    // User context
      user: string;
      role: string;
      ip: string;
    };
  };
  created_at: timestamp;
}

Setup

Prerequisites

PostgreSQL or MySQL database
Node.js runtime -the system (or compatible workflow system)

Deploy Mirrors

Each independent validator runs the mirror receiver:

Comparison Summary

Talaan Chain vs Blockchain

graph LR
    subgraph "Blockchain"
        BC[Public Ledger<br/>Global Consensus<br/>Cryptographic Security<br/>High Cost<br/>Complex Setup]
    end

    subgraph "Talaan Chain"
        TC[Private Ledger<br/>Distributed Validation<br/>Layered Security<br/>Low Cost<br/>Simple Setup]
    end

    subgraph "Best For"
        BC_USE[Cryptocurrency<br/>Public Records<br/>Trustless Systems<br/>Global Networks]
        TC_USE[Internal Audits<br/>Compliance Logs<br/>Organizational Data<br/>Controlled Access]
    end

    BC -.->|Designed for| BC_USE
    TC -.->|Designed for| TC_USE

    style BC fill:#E74C3C
    style TC fill:#50C878
    style TC_USE fill:#9B59B6

Choose Blockchain When:

You need a truly public, permissionless system
Participants are anonymous and potentially adversarial
You're handling cryptocurrency or tokenized assets
You need global consensus without trusted parties

Choose Talaan Chain When:

You need internal audit trails
You have trusted validator parties
You want fast performance and low cost
You need to integrate with existing systems
Your data must remain private

FAQ

Q: Is FNV-1a secure enough?

A: For controlled environments with layered security, yes. The combination of hash chaining + JWT signatures + distributed validation provides practical tamperproofing against internal threats.

Q: Can I use SHA-256 instead?

A: Yes, you can swap the hash function. But for most use cases, the bottleneck is network latency and database operations, not hash speed.

Q: How many mirrors do I need?

A: Minimum 2 (preferably 3+). Each mirror should be controlled by an independent party to prevent collusion.

Q: What if a mirror goes offline?

A: The system continues operating. Offline mirrors sync when they come back online. Having 3+ mirrors provides redundancy.

Q: Can I verify entries publicly?

A: Yes, via the Item Validator API. You can make this fully public or restrict to authenticated users.

Q: Does this work with any database?

A: Yes, any database that supports triggers and JSON fields. Tested with PostgreSQL, MySQL, and MariaDB.

Built for organizations that need blockchain-level integrity without blockchain complexity.

🔥 Why Talaan Chain? 🔗
Because corruption thrives in the dark — and we’re bringing transparency to light. 💡

Every log. Every change. Every action.
📜 Recorded. Chained. Tamperproof.

No more deleted evidence. No more excuses. 🚫
Just truth, accountability, and trust. 💪

TalaanChain #TransparencyTech #AntiCorruption #AuditRevolution #DataIntegrity

# Tamper-Evident Ledger Systems for National Budget Transparency

Trinmar Boado — Fri, 03 Oct 2025 02:40:34 +0000

Tamper-Evident Ledger Systems for National Budget Transparency

A Technology-Neutral Framework on Senate Bill 1330

📋 Project Overview

This contains a comprehensive position paper and framework for implementing Tamper-Evident Ledger Systems (TELS) to combat corruption in the Philippine National Budget. The framework addresses Senate Bill No. 1330 (Philippine National Budget Blockchain Act) with detailed amendments that transform it from a simple blockchain mandate into a robust accountability system.

🎯 Mission Statement

"To design accountability into the budget system so corruption becomes visible, traceable, punishable, and preventable."

This is not about "blockchaining the budget" - it's about creating a comprehensive framework where every peso has a clear parent, every change is logged, and corruption becomes suicidal rather than profitable.

🧭 Executive Summary

What: A technology-neutral Tamper-Evident Ledger System (TELS) that uses traditional databases for data storage and an immutable ledger for proof (hashes) to make corruption visible, traceable, punishable, and preventable.
How: Hybrid architecture (databases for data, ledger for verification), real-time oversight for COA, strict penalties, citizen dashboards, multi-sector oversight, and pilot-first rollout.
Why: Avoid costly, slow, and privacy-conflicting "blockchain everything" schemes; comply with the Data Privacy Act; achieve transparency with measurable outcomes.
Cost/ROI: Prioritize government‑run, permissioned ledger to avoid external per‑transaction fees; store data off‑chain and hashes on‑chain to minimize storage costs. See Cost-Benefit section for assumptions and formulas.
Legal Fit: Compliant with RA 10173 (Data Privacy), RA 8792 (E-Commerce), RA 10175 (Cybercrime), PD 1445 (Auditing), RA 9346 (no death penalty), RA 9184 (Procurement), RA 11032 (Ease of Doing Business), and EO No. 2 (2016) FOI.

🗂️ Table of Contents

Executive Summary
Objectives and Scope
Key Statistics
Critical Design Principles
Agency Integrations & Standards
Core Framework Components
Technical Architecture (Hybrid Model)
Cost-Benefit Analysis
Governance and RACI
Data Model and Dictionary (Excerpt)
Process Flows and SLAs
Traceability Map
Legal Reconciliation Matrix
Proposed Amendments to SB 1330
KPIs (Key Performance Indicators)
Risk Register (Top Risks and Controls)
Procurement and Costing (RA 9184)
Interoperability and Migration
Accessibility and Inclusion
Appendix: Examples
Roadmap
Security Considerations
Data Sovereignty & Residency
Legal Framework
FAQ
References
Related Resources

📚 Glossary (Selected)

TELS: Tamper-Evident Ledger Systems (tech-neutral immutability layer).
Hash: Digital fingerprint of a file/record used to verify integrity.
Structured Data: Tabular/JSON items (e.g., budget line items).
Unstructured Data: Files such as PDFs, images (receipts, contracts).
SLA: Service Level Agreement (deadline/quality target for a process).
RACI: Responsibility matrix (Responsible, Accountable, Consulted, Informed).

📊 Key Statistics

🎯 Objectives and Scope

Objectives: Make every peso traceable end-to-end; enable real-time oversight; deter tampering through evidence; empower citizens with usable transparency
Scope: DBM (appropriations/allotments), PhilGEPS (procurement), agencies (delivery/acceptance/accounting), BTr (cash release/disbursement), COA (real-time audit)
Out of scope: Storing raw documents on-chain; blockchain-only mandates; public L1 dependence for storage
Current Problem: ₱50M+ plunder threshold leaves smaller fraud unchecked
Proposed Penalties: Reclusion perpetua for ₱1M+ fraud; scaled punishments with asset forfeiture and perpetual disqualification (RA 9346-compliant)
Whistleblower Rewards: Up to ₱500M (5% of recovered funds)
Pilot Duration: 2 years in DBM, DPWH, and 3 LGUs
Technology Scope: Blockchain, DLT, DAG, ZKPs, and other immutable systems
Cost Reduction: 90% storage savings, 100% gas fee elimination
Data Privacy: Full RA 10173 compliance with correction rights

⚠️ Critical Design Principles

Blockchain = Proof, Not Storage 🎯

Problem: Misconception that blockchain should store everything
Reality: Blockchain is a fingerprint system, not a filing cabinet
Solution: Hybrid architecture - databases for data, blockchain for verification
Cost Impact: Prevents ₱60M+ storage costs and gas fees
Legal Compliance: Avoids Data Privacy Act conflicts

Structured vs Unstructured Data Architecture 📊

Structured Data (Budget items, allocations): JSON/CSV in databases
Unstructured Data (Receipts, contracts, documents): File repositories
Verification Layer: Only hashes stored on blockchain
Processing: Validation pipelines before blockchain commitment

Cost-Benefit Analysis 💰

Current Problem: ₱60M+ projects with unclear ROI
Proposed Solution: Pilot-first approach with measurable outcomes
Gas Fee Mitigation: Local blockchain nodes, not foreign hosting
Storage Costs: 99% reduction through hash-only approach

🔧 Core Framework Components

1. Severe Penalties for Fraud

Problem: Budget tampering treated as ordinary falsification
Solution: Scaled penalties compliant with RA 9346 (no death penalty): e.g., ₱1M+ → reclusion perpetua, perpetual disqualification, asset forfeiture; ₱500k–₱999,999 → reclusion temporal; ₱100k–₱499,999 → prisión mayor; with proportional fines.
Legal Basis: RPC Arts. 171–172; RA 7080; RA 9346 (prohibits death penalty)

2. Collusion Prevention

Problem: Validators may conspire to approve fake entries
Solution: Immutable logging + Reclusion Perpetua + ₱5B fine
Legal Basis: RPC Art. 217 (Malversation)

3. Immutable Amendment Logging

Problem: "Midnight insertions" lack traceability
Solution: Mandatory logging of proponent, signature, timestamp, justification
Legal Basis: RA 8792 (E-Commerce Act)

4. Real-Time COA Oversight

Problem: Delayed audits arrive after corruption is entrenched
Solution: Direct TELS access + quarterly independent audits
Legal Basis: Constitution, Art. IX-D

5. Transparency Enforcement

Problem: Officials delay/block budget data release
Solution: Non-compliance auto-flagged + Reclusion Temporal
Legal Basis: PD 1445 (Government Auditing Code)

6. Whistleblower Protection & Rewards

Problem: Insiders fear retaliation, no financial incentive
Solution: 5% reward (max ₱500M) + Witness Protection Program
Legal Basis: RA 6981

7. Citizen-Friendly Transparency

Problem: Data hidden in PDFs, technical jargon
Solution: Mobile dashboards, plain language, multilingual support; proactive disclosure aligned with FOI and RA 11032 (Ease of Doing Business)
Legal Basis: RA 9485 (Anti-Red Tape Act), RA 11032, EO No. 2 (2016) FOI

8. Independent Oversight Committee

Problem: Single-body monopoly over monitoring
Solution: Multi-sector committee (COA, Congress, academe, civil society)
Legal Basis: RA 3019 (Anti-Graft)

9. Phased Rollout Strategy

Problem: Big-bang IT projects often fail
Solution: 2-year pilot in DBM, DPWH, 3 LGUs before national rollout
Legal Basis: PD 1445

10. Cybersecurity & Resilience

Problem: Systems vulnerable to hacking and sabotage
Solution: Ledger Security Operations Center (SOC) + penetration testing
Legal Basis: RA 10175 (Cybercrime Prevention Act)

11. Technology-Neutral Systems

Problem: Bill prescribes blockchain only
Solution: TELS framework supporting blockchain, DLT, DAG, ZKPs, timestamping
Legal Basis: BusinessMirror critique (Ann Cuisia, Sept 2025)

12. Data Engineering Standards

Problem: Unstructured, inconsistent budget data
Solution: Unified schema, validation pipelines, structured/unstructured separation
Legal Basis: RA 8792, PD 1445

13. Blockchain as Proof, Not Storage

Problem: Misconception that blockchain should store everything
Solution: Hybrid model - hashes on-chain, full data in databases
Legal Basis: RA 10173 (Data Privacy Act), RA 8792

14. Data Privacy Act Compliance & Right to Correction

Problem: Immutable blockchain conflicts with citizen's right to correct/delete data
Solution: Correction requests logged on-chain, original data updated in databases
Process: Citizen requests → Validation → Database update → New hash on-chain
Legal Basis: RA 10173 (Data Privacy Act)

15. Cost-Effective Implementation Strategy

Problem: ₱60M+ projects with unclear ROI and foreign gas fees
Solution: Local blockchain nodes, hash-only storage, pilot validation
Cost Breakdown: 90% reduction in storage costs, 100% elimination of foreign gas fees
Legal Basis: RA 9184 (Government Procurement Reform Act)

🏗️ Technical Architecture (Hybrid Model)

┌─────────────────────────────────────────────────────────────────┐
│                    DATA LAYER (Databases)                      │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐            │
│  │ Structured  │  │Unstructured │  │   Metadata  │            │
│  │   Data      │  │    Data     │  │   & Logs    │            │
│  │ (JSON/CSV)  │  │(Files/PDFs) │  │ (Timestamps)│            │
│  └─────────────┘  └─────────────┘  └─────────────┘            │
└─────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│                VERIFICATION LAYER (TELS)                       │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐            │
│  │   Hash      │  │  Digital    │  │ Validation  │            │
│  │ Storage     │  │ Signatures  │  │  Rules      │            │
│  │(Blockchain) │  │(Immutable)  │  │(Smart Cont.)│            │
│  └─────────────┘  └─────────────┘  └─────────────┘            │
└─────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│                 TRANSPARENCY LAYER (APIs)                      │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐            │
│  │  Citizen    │  │   COA       │  │   Media     │            │
│  │ Dashboard   │  │  Real-time  │  │   Tools     │            │
│  │(Mobile/Web) │  │ Monitoring  │  │(Analytics)  │            │
│  └─────────────┘  └─────────────┘  └─────────────┘            │
└─────────────────────────────────────────────────────────────────┘

💰 Cost-Benefit Analysis

Current Problem (Traditional Approach)

Storage Costs: ₱60M+ for full data on blockchain
Gas Fees: ₱500k-₱2M monthly for foreign hosting
Performance: Slow transactions, high latency
Legal Risk: Data Privacy Act violations

Proposed Solution (Hybrid Model)

Storage Costs: ₱6M (90% reduction) - databases only
Gas Fees: ₱0 (local nodes, hash-only transactions)
Performance: Fast queries, real-time updates
Legal Compliance: Full Data Privacy Act compliance

ROI Calculation

Initial Investment: ₱15M (pilot phase)
Annual Savings: ₱25M (vs traditional blockchain)
Break-even: 7 months
5-year ROI: 800%

Assumptions and Sources (for estimation)

Let N_tx = number of budget events to anchor per year (e.g., line-item approvals, amendments, disbursements). Provide from DBM operations data.
Let S_doc_avg = average size of supporting documents per event (GB). Use your agency’s measured average; avoid guessing.
Object storage price p_store ≈ USD 0.023/GB-month (public benchmark, AWS S3 Standard) for estimation only: https://aws.amazon.com/s3/pricing/
If using public L1 storage/transactions: on Ethereum, calldata non‑zero bytes cost 16 gas/byte (EIP‑2028): https://eips.ethereum.org/EIPS/eip-2028; gas price varies (see Etherscan Gas Tracker): https://etherscan.io/gastracker. We avoid this by running permissioned, local nodes.
Local validator node cost: let c_node_month come from GOVCloud/DICT or IaaS quote (e.g., comparable to 2 vCPU/8GB VM reference price; see EC2 on‑demand reference: https://aws.amazon.com/ec2/pricing/). Use actual DICT/GovCloud prices in procurement.

Formulas

Annual object storage (documents) cost: Cost_docs_year = (Total_Doc_GB_month_average × 12) × p_store
If storing raw docs on public chain (not recommended):
- Per‑event gas: Gas_event ≈ 16 × bytes_calldata + base_gas_tx
- Annual gas USD: Cost_gas_year = N_tx × Gas_event × gas_price_gwei × 1e-9 × ETHUSD
Permissioned hash‑only anchoring cost: negligible gas; infra cost dominates.
- Infra annual cost: Cost_infra_year = N_nodes × c_node_month × 12
Hybrid total annual: Cost_hybrid_year = Cost_docs_year + Cost_infra_year

Example computation (replace with your real inputs)

Inputs (example):
- N_tx = 1,000,000 events/year
- Average attached documents 2 MB/event ⇒ Total_Doc_GB_month_average ≈ (1,000,000 × 2 MB) / (1024 MB/GB) / 12 ≈ 162.8 GB/month
- p_store = USD 0.023/GB‑month (reference)
- N_nodes = 5 permissioned validators; c_node_month = USD 60/month (reference VM; replace with DICT/GovCloud quote)
Calculations:
- Cost_docs_year = 162.8 × 12 × 0.023 ≈ USD 44.9/year
- Cost_infra_year = 5 × 60 × 12 = USD 3,600/year
- Cost_hybrid_year ≈ USD 3,645/year (documents in object storage; hashes on chain; local nodes)

For comparison only (do NOT implement): storing 2 MB/event as calldata on a public chain with bytes_calldata ≈ 2,000,000, base_gas_tx ≈ 21,000, gas_price = 20 gwei, ETHUSD = 3,000:

Gas_event ≈ (16 × 2,000,000) + 21,000 = 32,021,000 gas
Cost_event_USD ≈ 32,021,000 × 20e-9 × 3,000 ≈ USD 1,921.26
Annual_gas ≈ 1,000,000 × 1,921.26 = USD 1.92B (illustrates why “blockchain = storage” is economically infeasible)

These examples use public reference prices (cited) and standard gas formulas (EIP‑2028). Replace all placeholders with official DICT/GovCloud price quotes and DBM volumes during procurement.

🧑‍⚖️ Governance and RACI (Summary)

DBM (Owner): Operates data pipelines; enforces submission SLAs; publishes datasets and metadata.
COA (Oversight): Real-time audit access; runs anomaly analytics; issues audit observations.
DICT (Platform/SOC): Runs infrastructure, validator nodes, HSM/key management, incident response.
Oversight Committee: Multi-sector (COA, Congress, academe, civil society, private sector) issuing quarterly public reports in TELS.
RACI per Process: Submission (Agency R/DBM A); Validation (DBM R/DICT C/COA I); Commit (DICT R, DBM A); Correction (DBM R, COA C, Citizen I); Non-compliance (DBM A, COA I, Oversight I).

🗃️ Data Model and Dictionary (Excerpt)

Structured Budget Item (minimum fields)

agencyId, programCode, lineItemId, uacsCode, fundSource, amount, locationCode
proponentId, approverId, validatorIds[], justificationText
createdAt, approvedAt, amendedAt, attachmentHashes[]

Unstructured Document Metadata

documentType (receipt, contract, payroll, invoice), issuer, dateIssued
fileChecksum (SHA-256), storageUri, retentionPolicy

Classification Levels

Public, Restricted (personal), Confidential (security), Secret (if applicable)

Validation pipelines shall reject records missing required fields or failing schema/consistency checks.

Procurement (OCDS-aligned) Core Entities

Planning (budget and procurement plan linkage): ocid, buyer.id, budget.breakdownID, telsTraceId
Tender (notice): ocid, id, title, status, tenderPeriod, items[], value.amount, procurementMethod
Award: ocid, id, suppliers[], value.amount, date, documents[].hash
Contract: ocid, id, awardID, dateSigned, value.amount, implementation.milestones[], documents[].hash

References: Open Contracting Data Standard (OCDS) schema: https://standard.open-contracting.org/latest/en/

Disbursement and Treasury Linkages

ObligationRequest (OBR): obrId, agencyId, uacsCode, amount, fundSource, telsTraceId, digitalSignatures[]
DisbursementVoucher (DV): dvId, supplierId, contractId, amountGross, taxes, amountNet, telsTraceId, attachmentHashes[]
CashRelease (BTr): ncaId, dvId, amount, releaseDate, bankRef, telsTraceId

All financial postings reference UACS codes and carry telsTraceId for cross-system correlation.

🔄 Process Flows and SLAs

1) Submission

Agency encodes records → Schema validation (≤ 2 hours) → Queue for validation

2) Validation

Automated checks (UACS totals, duplicates, range checks) + role-based approvals (≤ 2 days)

3) Commit

Write to databases → Generate hash → Anchor hash on TELS (≤ 1 hour)

4) Correction (Data Privacy Act)

Request intake (portal) → Identity verification → Review (≤ 10 days)
Database update → New hash on TELS → Immutable audit trail preserved

5) Non-compliance

Auto-flag missed deadlines → Notify COA and Oversight Committee

Signatories and Digital Signatures (PNPKI)

Each critical event is signed by role holders using PNPKI-qualified certificates:
- Agency Budget Officer (submission)
- BAC Chair/Secretariat (tender/bid events)
- HOPE (award/contract approval)
- Inspection/Acceptance Committee (IAR)
- Accounting Officer (OBR/DV)
- Agency Head/Authorized Signatory (DV approval)
- BTr Authorized Officer (cash release)
digitalSignatures[] contains signer commonName, issuer, serialNumber, signatureAlgorithm, signature, and signedAt.
Signature hashes and certificate chains are anchored in TELS for verification.

🔗 Traceability Map (Keys and Joins)

telsTraceId: Shared across all stages to link records end-to-end
ocid: Links PhilGEPS Planning/Tender/Award/Contract artifacts
uacsCode: Standard accounting codes for classification and checks
contractId ↔ dvId/obrId: Connects contract obligations to disbursements
ncaId ↔ dvId: Connects cash allocations to payments
documents[].hash and attachmentHashes[]: Verify documents consistently across systems

⚖️ Legal Reconciliation Matrix (Highlights)

RA 10173 (Data Privacy Act) right to rectification vs immutability
- Store mutable data in database; record correction events on TELS; keep verifiable history
PD 1445 (Auditing) timely submissions
- Auto-flags for missing/late entries; penalties for obstruction; COA alerting
RA 9346 (No Death Penalty)
- Penalty scaling uses reclusion and asset forfeiture, not capital punishment
RA 8792 (E-Commerce) electronic signatures
- Require digital signatures on amendments; signature evidence logged in TELS

📊 KPIs (Key Performance Indicators)

Transparency Coverage: % of budget lines with publicly verifiable hashes (TELS events)
Timeliness: Median time from submission → commit (process logs)
Correction SLA: % of requests completed within 15 days (correction module)
Audit Lead Time: Days from spend to COA visibility (access logs)
Data Quality: % of records passing validation on first submission
Public Engagement: Dashboard users, API calls, FOI-linked queries
Deterrence: Year-over-year reduction in anomalies flagged

☂️ Risk Register (Top Risks & Controls)

Legal challenge on penalties → Align with jurisprudence; DOJ/OGCC review
Adoption resistance → Training, change champions, executive directives
Data quality issues → Mandatory schema validation; agency scorecards; escalation
Vendor lock-in → Tech-neutral specs; open standards; modular procurement lots
Security breach → HSM key custody; node quorum/BFT; red teaming; DR drills

🧾 Procurement and Costing (RA 9184)

Lots: Core platform, SOC services, integration adapters, citizen dashboard, training
Evaluation: QCBE with technical scoring; open standards compliance mandatory
Milestones/Payments: Pilot deploy → COA integration → Dashboard live → Independent audit pass
Licensing: Prefer permissive/open-source; publish non-sensitive components

🔌 Interoperability and Migration

Integrations: DBM budget systems (eBudget, BTMS), COA eNGAS/eBudget, PhilGEPS, Bureau of the Treasury (BTr) Cash Management
Canonical schema adapters; API gateways; event streaming for updates
Migration: Prioritize current fiscal year; backfill prior 3 years’ hashes progressively

Agency Integration Flows (high level)

DBM → Appropriations, allotments, SARO/NCAs; publishes structured records; TELS anchors hashes and metadata
PhilGEPS → Procurement notices, bids, awards, contracts (OCDS-aligned); TELS anchors award and contract hashes
Procuring Entity (Agency) → Delivery/inspection/acceptance (IAR), billing, DV/OBR; TELS anchors receiving and acceptance events
BTr → Cash releases and disbursement confirmations; TELS anchors payment proofs and references to NCA/SAA

All inter-agency events share a common Trace ID to enable end-to-end linkage (Appropriation → Allotment → Procurement → Contract → Delivery → Billing → Disbursement).

🏛️ Agency Integrations & Standards

DBM: Appropriations, Allotments (SARO), Notices of Cash Allocation (NCA); UACS-coded; publishes structured records; hashes anchored in TELS
PhilGEPS: OCDS-aligned procurement data: Planning, Tender, Award, Contract; publish documents with hashes; expose APIs for TELS anchoring
Agencies (PEs): Delivery, Inspection & Acceptance (IAR), Billing Statements, OBR/DV with attachments; sign via PNPKI; anchor events in TELS
BTr: Cash releases and disbursement confirmations; references DV/NCA; anchor proof records and bank refs in TELS
COA: Real-time audit access; anomaly analytics; quarterly public reporting via Oversight Committee

Standards: UACS (DBM-COA-DOF JC 2013-1), OCDS (Open Contracting), PNPKI (DICT), FOI/RA 11032 compliance, Data Privacy (RA 10173).

🌍 Accessibility and Inclusion

WCAG 2.1 AA; simple Filipino/English + regional languages
Mobile-first; low-bandwidth mode; printable summaries

📎 Appendix: Examples

A. Sample JSON Schema: `BudgetItem`

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "BudgetItem",
  "type": "object",
  "required": [
    "agencyId", "programCode", "lineItemId", "uacsCode",
    "amount", "fundSource", "proponentId", "approverId", "createdAt"
  ],
  "properties": {
    "agencyId": { "type": "string" },
    "programCode": { "type": "string" },
    "lineItemId": { "type": "string" },
    "uacsCode": { "type": "string" },
    "amount": { "type": "number", "minimum": 0 },
    "fundSource": { "type": "string" },
    "locationCode": { "type": "string" },
    "proponentId": { "type": "string" },
    "approverId": { "type": "string" },
    "validatorIds": { "type": "array", "items": { "type": "string" } },
    "justificationText": { "type": "string" },
    "attachmentHashes": { "type": "array", "items": { "type": "string" } },
    "createdAt": { "type": "string", "format": "date-time" },
    "approvedAt": { "type": "string", "format": "date-time" },
    "amendedAt": { "type": "string", "format": "date-time" }
  }
}

B. Correction Request Flow (DPA-Compliant)

{
  "requestId": "REQ-2025-0001",
  "requestor": { "fullName": "Juan Dela Cruz", "id": "CIT-12345" },
  "recordRef": { "type": "BudgetItem", "lineItemId": "LI-2025-0456" },
  "claimedError": "Incorrect amount encoding",
  "proposedFix": { "amount": 1250000 },
  "submittedAt": "2025-10-03T09:00:00Z",
  "status": "UNDER_REVIEW",
  "slaDays": 10
}

C. Verify File Hash API (Proof, not Storage)

Request

GET /api/v1/verify?lineItemId=LI-2025-0456&docHash=0xabc123...

Response

{
  "lineItemId": "LI-2025-0456",
  "docHash": "0xabc123...",
  "anchored": true,
  "blockHeight": 128945,
  "anchoredAt": "2025-10-03T10:05:00Z",
  "signers": ["DICT-VALIDATOR-01", "COA-NODE-02"],
  "verdict": "MATCHES_ON_CHAIN"
}

🧩 Proposed Amendments to SB 1330 (Technology-Neutral TELS)

1) Title and Definitions

Replace references to “blockchain” with “Tamper-Evident Ledger Systems (TELS)” defined as technology-neutral systems providing cryptographic immutability and public verifiability, including but not limited to DLT, blockchain, DAGs, append-only cryptographic logs, secure timestamping, and zero-knowledge systems.

2) Storage vs Proof

Clarify that full records remain in government databases or repositories; only digital fingerprints (hashes), timestamps, signatures, and minimal metadata shall be recorded on TELS for verification.

3) Mandatory Amendment Logging

Require that every insertion, realignment, or change include the proponent’s name/office, justification, timestamp, digital signature, and validator/approver identity; all actions recorded in TELS.

4) COA Real-Time Access

Mandate COA real-time read access to TELS and associated APIs; allow COA-accredited independent audits at least quarterly.

5) Transparency and FOI Compliance

Require citizen-friendly dashboards, open APIs, multilingual support, and proactive disclosure aligned with EO No. 2 (2016) FOI and RA 11032.

6) Data Privacy and Corrections

Establish a correction process compliant with RA 10173: corrections occur in databases; corresponding correction events (new hashes) logged to TELS, preserving an immutable trail.

7) Penalties (RA 9346-Compliant)

Scale penalties without capital punishment: ₱1M+ → reclusion perpetua + perpetual disqualification + asset forfeiture; ₱500k–₱999,999 → reclusion temporal; ₱100k–₱499,999 → prisión mayor; with proportional fines and administrative sanctions for obstruction/non-submission.

8) Cybersecurity & Node Governance

Direct DICT to operate a Ledger SOC; require at least five validator nodes (DICT, COA, DBM, academe, independent auditor) with BFT quorum; mandate HSM-backed key management and regular penetration testing.

9) Phased Rollout and Evaluation

Implement a two-year pilot (DBM, DPWH, at least 3 LGUs); proceed to national rollout only after an independent evaluation confirms success against KPIs.

10) Procurement and Tech Neutrality

Procure via RA 9184 using tech-neutral specifications, open standards, modular lots, and milestone-based payments; prefer permissive/open-source components where feasible.

11) Cost Controls and Data Residency

Prioritize local nodes; prohibit mandatory use of foreign chains incurring gas fees; require cost/benefit disclosure; comply with DICT Cloud First and data residency guidance.

12) Citizen Participation and Whistleblowers

Provide whistleblower rewards up to 5% of recovered funds (cap), WPP protection per RA 6981; enable citizen reporting channels linked to TELS events.

Note: Drafting style and section numbering should align with the enrolled version of SB 1330 under consideration.

WCAG 2.1 AA; simple Filipino/English + regional languages
Mobile-first; low-bandwidth mode; printable summaries

🚀 Implementation Roadmap

Phase 1: Foundation (Months 1-6)

[ ] Legal framework finalization
[ ] Technology selection and procurement
[ ] Pilot agency selection (DBM, DPWH, 3 LGUs)
[ ] Security architecture design

Phase 2: Pilot Implementation (Months 7-30)

[ ] TELS deployment in pilot agencies
[ ] Data migration and standardization
[ ] COA integration and real-time monitoring
[ ] Citizen dashboard development

Phase 3: Evaluation & Scaling (Months 31-36)

[ ] Independent pilot evaluation
[ ] Performance metrics analysis
[ ] National rollout planning
[ ] Full-scale deployment

🔍 Key Features

Immutable Logging: Every budget change permanently recorded
Real-Time Monitoring: COA and public oversight in real-time
Scalable Penalties: Punishment proportional to fraud amount
Whistleblower Protection: Financial incentives and legal protection
Technology Neutral: Not locked into specific blockchain technology
Citizen Access: User-friendly interfaces for public engagement
Multi-Sector Oversight: Prevents elite capture of monitoring systems

📈 Expected Outcomes

Transparency: 100% of budget changes publicly traceable
Accountability: Clear ownership of every peso spent
Deterrence: Severe penalties make corruption financially suicidal
Engagement: Citizens actively monitor budget through accessible tools
Efficiency: Real-time oversight prevents corruption before it spreads
Trust: Restored public confidence in government financial management

🛡️ Security Considerations

Ledger Security Operations Center (SOC): 24/7 monitoring
Penetration Testing: Regular security assessments
Disaster Recovery: Redundant systems and backup procedures
Data Privacy Compliance: Full adherence to RA 10173
Multi-Factor Authentication: Enhanced access controls

🗺️ Data Sovereignty & Residency

National systems (budget, tax, treasury) must operate on infrastructure under Philippine jurisdiction and control
Prohibit mandatory reliance on foreign-controlled public chains for core records; use permissioned, locally governed nodes
Store full records in government-managed databases; anchor only hashes to a state-governed ledger
Require data residency per DICT Cloud First and applicable regulations; document locations, custodians, and failover sites
Disclose any third-party chain dependencies; provide exit/migration plans and on-prem verification mirrors

References: DICT Cloud First Policy (DC 2020-002): https://dict.gov.ph/cloud-first-policy/

📚 Legal Framework

The framework is grounded in existing Philippine laws:

RPC Arts. 171-172: Falsification penalties
RA 7080: Plunder law
RA 8792: E-Commerce Act
RA 10175: Cybercrime Prevention Act
RA 10173: Data Privacy Act
PD 1445: Government Auditing Code

🤝 Contributing

This framework is designed for public input and collaboration. Key stakeholders include:

Government Agencies: DBM, COA, DICT, Congress
Civil Society: Transparency advocates, watchdog groups
Academia: Research institutions, policy experts
Private Sector: Technology providers, auditors
Citizens: End users and beneficiaries

❓ Frequently Asked Questions (Addressing Key Concerns)

Q1: Why not just put everything on blockchain?

A: Blockchain is a fingerprint system, not a filing cabinet. Storing all data on-chain would:

Cost ₱60M+ in storage fees
Require ₱500k-₱2M monthly gas fees for foreign hosting
Violate Data Privacy Act (right to correction/deletion)
Make the system slow and expensive

Q2: How do we handle data correction requests under Data Privacy Act?

A: Hybrid model allows corrections:

Citizen requests correction through official channels
Request is validated and logged on blockchain
Original data is updated in database
New hash is generated and stored on blockchain
Full audit trail maintained

Q3: What's the difference between structured and unstructured data?

Structured: Budget items, allocations (JSON/CSV) → Fast queries, easy analysis
Unstructured: Receipts, contracts, documents (PDFs/images) → File storage, hash verification
Processing: Validation pipelines ensure data quality before blockchain commitment

Q4: How do we prevent the ₱60M+ project failure?

Start with ₱15M pilot (2 years)
Measure concrete outcomes before scaling
Local blockchain nodes (no foreign gas fees)
Hash-only storage (90% cost reduction)
Independent evaluation before national rollout

Q5: Who pays for gas fees and infrastructure?

Gas Fees: ₱0 (local nodes, no foreign hosting)
Infrastructure: Government-owned blockchain nodes
Storage: 90% reduction through hash-only approach
Total Cost: ₱6M vs ₱60M+ traditional approach

Q6: How do we ensure this isn't just another IT project?

Focus on accountability outcomes, not technology
Real-time COA oversight and citizen monitoring
Severe penalties make corruption financially suicidal
Multi-sector oversight prevents elite capture
Measurable anti-corruption metrics

Q7: What happens if the blockchain is hacked?

Ledger Security Operations Center (SOC) 24/7 monitoring
Regular penetration testing and security audits
Disaster recovery and backup systems
Hash verification allows detection of any tampering
Multiple validation layers prevent single points of failure

Q8: How do citizens actually use this system?

Mobile-first dashboards with plain language
Visual analytics and graphs
Multilingual support (Tagalog, Cebuano, Ilocano)
Open APIs for journalists and civic tech
Real-time alerts for budget changes

🔗 Related Resources

SB 1330 context article: https://edgedavao.net/latest-news/2025/09/blockchain-budget-bill-filed-in-the-senate-to-boost-transparency-fund-classrooms/
Background explainer: https://medium.com/thecapital/blockchain-the-budget-bill-sbn-1330-revolutionizing-fiscal-transparency-in-the-philippines-4968846ad713
Open Contracting Data Standard (OCDS): https://standard.open-contracting.org/
COA (Commission on Audit): https://www.coa.gov.ph/
PhilGEPS (Philippine Government Electronic Procurement System): https://philgeps.gov.ph/
DICT Cloud First Policy: https://dict.gov.ph/cloud-first-policy/
PNPKI (eGovernment Public Key Infrastructure): https://dict.gov.ph/programs/electronic-government/
UACS (DBM-COA-DOF Joint Circular No. 2013-1): https://www.dbm.gov.ph/index.php/letters-and-circulars/other-releases/295-joint-circular-no-2013-1
NISTIR 8202: Blockchain Technology Overview (NIST): https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf
EIP-2028: Calldata Gas Cost Reduction: https://eips.ethereum.org/EIPS/eip-2028
Etherscan Gas Tracker: https://etherscan.io/gastracker
AWS S3 Pricing (object storage benchmark): https://aws.amazon.com/s3/pricing/
- NISTIR 8202: Blockchain Technology Overview (NIST): https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf
- Open Contracting Data Standard (OCDS) documentation: https://standard.open-contracting.org/latest/en/
- Open Contracting: Evidence and Results (impact brief): https://www.open-contracting.org/impact/
- EIP-2028: Calldata gas cost reduction (for cost comparisons): https://eips.ethereum.org/EIPS/eip-2028
- Etherscan Gas Tracker (reference gas prices): https://etherscan.io/gastracker
- AWS S3 pricing (object storage benchmark): https://aws.amazon.com/s3/pricing/
- DICT PNPKI/eGovernment PKI: https://dict.gov.ph/programs/electronic-government/
- PhilGEPS portal: https://philgeps.gov.ph/
- COA publications and circulars: https://www.coa.gov.ph/publications/
- DBM Budget Documents: https://www.dbm.gov.ph/index.php/budget-documents ### 📚 References (Authoritative Links)
1987 Constitution, Art. IX-D (Commission on Audit): https://www.officialgazette.gov.ph/constitutions/1987-constitution/
Presidential Decree No. 1445 (Government Auditing Code): https://lawphil.net/statutes/presdecs/pd1978/pd_1445_1978.html
Republic Act No. 10173 (Data Privacy Act): https://www.privacy.gov.ph/data-privacy-act/
Republic Act No. 8792 (E-Commerce Act): https://lawphil.net/statutes/repacts/ra2000/ra_8792_2000.html
Republic Act No. 9346 (Prohibiting Death Penalty): https://lawphil.net/statutes/repacts/ra2006/ra_9346_2006.html
Republic Act No. 9184 (Government Procurement Reform Act): https://www.gppb.gov.ph/laws/laws/RA_9184.pdf
Republic Act No. 3019 (Anti-Graft and Corrupt Practices Act): https://www.officialgazette.gov.ph/1960/08/17/republic-act-no-3019/
Republic Act No. 11032 (Ease of Doing Business): https://www.officialgazette.gov.ph/2018/05/28/republic-act-no-11032/
Executive Order No. 2, s. 2016 (Freedom of Information): https://www.officialgazette.gov.ph/2016/07/23/executive-order-no-2-s-2016/
DICT Cloud First Policy (DC 2020-002): https://dict.gov.ph/cloud-first-policy/
National Cybersecurity Plan 2022 (DICT): https://dict.gov.ph/ncp2022/
DBM-COA-DOF Joint Circular No. 2013-1 (UACS): https://www.dbm.gov.ph/index.php/letters-and-circulars/other-releases/295-joint-circular-no-2013-1
Open Contracting Data Standard (OCDS): https://standard.open-contracting.org/
PhilGEPS: https://philgeps.gov.ph/
PNPKI (eGov PKI): https://dict.gov.ph/programs/electronic-government/

Important: SBN-1330 number may refer to different topics across Congresses; ensure citations target the correct filing/version being amended.

SB 1330 coverage article (context): https://edgedavao.net/latest-news/2025/09/blockchain-budget-bill-filed-in-the-senate-to-boost-transparency-fund-classrooms/
Background explainer: https://medium.com/thecapital/blockchain-the-budget-bill-sbn-1330-revolutionizing-fiscal-transparency-in-the-philippines-4968846ad713
COA: https://www.coa.gov.ph/
DICT: https://dict.gov.ph/

⚠️ Important Note: This framework transforms SB 1330 from a simple blockchain mandate into a comprehensive anti-corruption system. The focus is on accountability, transparency, and deterrence - not just technology implementation.

✅ Success Metric: When corruption becomes visible, traceable, punishable, and preventable rather than profitable and hidden.

🧩 The Habit of Asking WHY — Unlocking Purpose, Innovation & Connection

Trinmar Boado — Tue, 24 Jun 2025 15:28:24 +0000

1. The Power of Why — More Than Just a Question

🔎 Clarifying Purpose

Asking “Why am I doing this?” connects daily actions to broader goals and boosts motivation.
Simon Sinek’s Golden Circle shows that leaders who start with Why inspire trust and loyalty by appealing to the emotional (limbic) brain before sharing How and What.

⚙️ Solving Root Problems

The Five Whys technique—originating from Toyota—recommends asking “why?” five times to identify underlying causes rather than surface-level symptoms.

🧠 Stimulating Innovation & Critical Thinking

Persistent questioning challenges assumptions, uncovers hidden truths, and spurs creativity and problem-solving.

2. When Asking Why Can Backfire

⚠️ Overthinking & Paralysis

Excessive “why” questions can derail decision-making if context or direction isn't maintained.

🛡️ Triggering Defensiveness

In sensitive situations, asking “why” bluntly can sound accusatory. Rephrasing with “What’s the reason…” or “Help me understand…” helps foster openness and psychological safety.

3. How to Ask Why Right

Technique	When to Use	How It Helps
Five Whys	Root-cause analysis	Systematically drills down to true causes
Socratic questioning	Learning/reflection	Builds deep insight through guided inquiry
Probing questions (“Can you give an example?”)	Feedback & ideas	Encourages elaboration and clarity
Softened why (“What’s the intent…?”)	Sensitive topics	Reduces defensiveness

4. A Narrative That Hooks

“Late last night, I stared at my screen debating a ‘share’ button.

I paused. Who needs it?

The next morning, I asked two users. Neither cared.

So I scrapped it.

And it saved us time, money — and sanity.”

This mini-story uses emotion, stakes, and payoff to illustrate the moment of choice driven by asking why.

5. Real-World Impact

🚀 Innovation

Asking why has led to breakthroughs—from electric vehicles to disruptive learning models.

🧩 Team Effectiveness

Teams that routinely ask why in retrospectives uncover blockers faster and foster innovation.

❤️ Deeper Relationships

Asking “Why does that matter to you?” shifts conversations from assumptions to empathy and genuine connection.

6. Soft Tips for Everyday Use

Be intentional: Know when you want deeper insight—and when you just need decisions.
Blend questions: Add “how”, “what if”, “why not” to vary tone.
Listen actively: Pause, reflect, and validate before asking again.
Frame with care: Use prefacing phrases like “Help me understand…”.
Self-reflect first: Ask yourself why something matters before questioning others.

7. Science‑Backed Benefits

Memory & learning: “Why” activates deeper brain circuits and improves retention.
Behavioral alignment: Explicitly asking why increases follow-through (the mere-measurement effect).
Purpose alignment: Clarifying why aligns tasks with values—boosting motivation and clarity.

8. Building a Habit

Ritualize it: Begin meetings with “What’s our real why here?”
Reflect in writing: Journal weekly on which whys felt energizing.
Celebrate purpose-led decisions: Acknowledge when asking “why” led to better outcomes.
Track results: Note if clarifying purpose improved delivery, creativity, or satisfaction.

9. Final Challenge

Before your next decision—whether it's a feature, ask, or initiative—pause and ask:

Do we really need this?
Why would it matter or delight someone?

If both answers “spark energy” — proceed.
If not — refine, delay, or scrap.

🙌 In Summary

Asking WHY gives us:

🔍 Clarity by addressing root issues
⚖️ Purpose-driven focus
💡 Innovative thinking
💬 Deeper empathy and connection

Used thoughtfully—structured, softened, and strategic—asking why transforms tasks into meaningful choices, ideas into breakthroughs.

Ask purposefully. Listen deeply. Act meaningfully.

# Best Practices for Project Management (Focused on Productivity, Not Meetings)

Trinmar Boado — Thu, 06 Feb 2025 07:04:53 +0000

1. Essential Roles (No Unnecessary Overhead)

✅ Project Lead / Manager – Ensures project stays on track, removes blockers (not a micromanager).

✅ Team Members – Skilled professionals who do the actual work, empowered to make decisions.

✅ Stakeholder(s) – Those who define business goals but don’t micromanage execution.

❌ What to Avoid:

Useless roles like "Scrum Master" enforcing process over progress.
"Product Owner" who exists only to relay messages from executives.

2. Minimal Set of Artifacts (Only What’s Useful)

✅ Project Roadmap – High-level plan with milestones, kept flexible.

✅ Task Board (Kanban or Simple Backlog) – A visible list of tasks that matter, updated as needed.

✅ Deliverables Tracker – Tracks what’s actually getting done, not just estimated velocity.

❌ What to Avoid:

Overloaded "Sprint Backlogs" that never get fully completed.
Detailed documentation that no one reads (keep it lean & relevant).

3. Efficient Rituals (No Time-Wasting Meetings)

✅ One Weekly Check-In (Max 30 Minutes) – Focus on blockers and actual progress, not status updates.

✅ Async Daily Updates (if needed) – Quick Slack/Teams updates instead of daily stand-ups.

✅ Retrospectives Only When Needed – Instead of scheduled retros, do a lessons-learned session after milestones.

❌ What to Avoid:

Daily Standups where people just say "what they did" without real problem-solving.
Sprint Reviews that turn into long-winded PowerPoint sessions.
Forced Retros where no one has real feedback, but they have to say something.

4. Execution Focused on Real Progress

✅ Work in Iterations (but Flexible) – Weekly or bi-weekly releases, not fixed 2-week sprints that create artificial pressure.

✅ Limit Work in Progress (WIP) – Don’t start everything at once; focus on getting things done.

✅ Fast Decision-Making – Team makes quick, local decisions instead of waiting for approvals.

Summary: The Lean, No-BS Framework for Productivity

Roles: Only what’s necessary (Project Lead, Team, Stakeholders).
Artifacts: Just enough structure (Roadmap, Task Board, Deliverables Tracker).
Rituals: Only meet when necessary (Weekly check-ins, Async updates).
Execution: Deliver fast, adapt, and avoid bureaucratic overhead.

Software Dev Roles and Salary ranges in the Philippines (2024)

Trinmar Boado — Tue, 03 Dec 2024 13:32:33 +0000

Software engineering in the Philippines is evolving rapidly, offering lucrative opportunities for professionals across different skill levels. Whether you're just starting or are already a seasoned expert, this guide outlines the key knowledge areas and salary expectations for entry-level to principal-level engineers. Let’s dive in!

1. Entry-Level Engineers

What to Expect:
- Basic understanding of HTML, CSS, and JavaScript.
- Familiarity with at least one backend programming language like Python or PHP.
- Knowledge of Git for version control and basic debugging techniques.
Roles: Often found in startups or smaller firms, focusing on simple tasks like bug fixing and building small features.
Salary Range: PHP20,000 - PHP40,000/month.

2. Junior Engineers

What to Expect:
- Proficiency in front-end frameworks (e.g., React, Angular).
- Basic database design (e.g., MySQL, PostgreSQL).
- Experience with API consumption and exposure to Agile methodologies.
Roles: Collaborating with teams on building features, handling integration tasks, and starting to handle small modules independently.
Salary Range: PHP40,000 - PHP60,000/month.

3. Mid-Level Engineers

What to Expect:
- Strong expertise in both front-end and backend frameworks (e.g., Node.js, Django).
- Capable of building and deploying APIs and understanding CI/CD pipelines.
- Familiarity with cloud platforms like AWS, Azure, or GCP.
Roles: Responsible for designing modules, optimizing performance, and leading small teams.
Salary Range: PHP60,000 - PHP100,000/month.

4. Senior Engineers

What to Expect:
- Advanced problem-solving and fullstack expertise.
- Proficiency in DevOps tools like Kubernetes and Docker.
- Experienced in designing scalable systems and leading project teams.
Roles: Designing end-to-end systems, optimizing infrastructure, and mentoring junior developers.
Salary Range: PHP100,000 - PHP150,000/month.

5. Principal Engineers

What to Expect:
- Expertise in system architecture design and cross-team leadership.
- Ability to scale applications, optimize cloud costs, and ensure security compliance.
- Establishing technical standards and mentoring teams.
Roles: Leading entire engineering teams, defining architecture strategies, and making company-wide technical decisions.
Salary Range: PHP150,000 - PHP250,000+/month.

Key Takeaways

Growth Opportunities: The transition from junior to senior roles requires mastering not just technical skills but also leadership and strategic thinking.
Salary Variance: High-end salaries are typically offered by multinational companies or firms located in tech hubs like Metro Manila.
In-Demand Skills: Cloud computing (AWS, GCP), DevOps tools (Kubernetes, Terraform), and frontend frameworks (React, Vue) are top skills in demand for 2024.

With the software engineering field booming in the Philippines, there's no better time to advance your skills and grow your career. Whether you're building your foundation or aiming for leadership roles, the possibilities are endless!

Sources:

Philippine Salary Guide 202410.
Software Engineer Trends in the Philippines11.

Effective Communication in Daily Stand-Up Meetings for Software Developers

Trinmar Boado — Fri, 31 May 2024 09:10:21 +0000

Effective Communication in Daily Stand-Up Meetings for Software Developers

Daily stand-up meetings are a cornerstone of Agile methodology, offering a dedicated platform for team members to synchronize their activities, share progress, and identify any blockers. For software developers, these meetings are critical for ensuring smooth project execution. Mastering the language and flow of stand-up meetings can significantly enhance your communication skills and overall productivity. Here, we’ll explore common phrases and sentences that can help you sound more confident and articulate during these meetings.

Starting the Update

When initiating your update, it’s important to clearly and concisely communicate what you worked on previously. This sets the context for your current status and helps the team understand your progress.

"Yesterday, I worked on..."

This phrase helps you kick off your update by highlighting your previous day's activities. For example, "Yesterday, I worked on debugging the login feature." By starting with what you accomplished the day before, you provide a clear picture of your recent efforts and set the stage for the current day’s tasks.
"In the last 24 hours, I focused on..."

This variation offers a broader time frame, encompassing all activities since the last stand-up. For example, "In the last 24 hours, I focused on implementing the new payment gateway." This phrase can be particularly useful when your work spans across multiple areas or involves significant changes that require more context.
"I've been working on..."

This phrase is useful for ongoing tasks, indicating continuity in your efforts. For example, "I've been working on optimizing the database queries." Using this phrase can help your team understand that you are in the middle of a larger task that spans several days, providing a sense of continuity and progress.

Current Tasks

Clearly outlining your current tasks helps the team understand what you’re focusing on today. This also sets expectations for what you aim to achieve.

"Today, I plan to..."

This phrase clearly indicates your intentions for the day. For example, "Today, I plan to complete the unit tests for the shopping cart feature." By specifying your plan for the day, you give your team a clear understanding of your immediate goals and how they fit into the larger project timeline.
"My main focus today will be..."

This variation highlights your primary objective, ensuring that the team knows your top priority. For example, "My main focus today will be on fixing the critical bugs reported by QA." This helps to emphasize the most important task on your agenda, signaling to your team what you believe requires the most attention and effort.
"I'm currently working on..."

This phrase helps update the team on your immediate activities. For example, "I'm currently working on integrating the third-party API." It provides a snapshot of your current focus and how it contributes to the project’s progress.

Blocking Issues

Identifying and communicating blockers is essential for resolving issues quickly and keeping the project on track.

"I'm facing an issue with..."

This phrase helps you introduce a specific problem you’re encountering. For example, "I'm facing an issue with the API authentication." By clearly stating your issue, you open the door for team members to offer solutions or assistance.
"I'm blocked by..."

This direct approach clearly states what’s preventing you from making progress. For example, "I'm blocked by the lack of access to the staging server." Identifying blockers promptly allows the team to address them quickly, ensuring that progress can continue smoothly.
"One challenge I'm encountering is..."

This phrase allows for a more detailed explanation of the problem. For example, "One challenge I'm encountering is the inconsistency in the data returned by the API." Providing specific details about your challenges can help the team understand the complexity of the issue and collaborate on finding a solution.

Progress and Achievements

Highlighting your achievements and progress helps maintain a positive tone and demonstrates your contributions to the project.

"I've completed..."

This phrase succinctly conveys task completion. For example, "I've completed the user interface for the dashboard." Celebrating small victories and completed tasks boosts morale and keeps the team motivated.
"I finished the task related to..."

This variation provides context for the completed task. For example, "I finished the task related to implementing the new search functionality." Offering context helps the team understand the significance of your completed work and how it fits into the overall project.
"I made progress on..."

This phrase is useful for ongoing tasks, indicating forward movement. For example, "I made progress on optimizing the loading time for the homepage." Highlighting incremental progress keeps the team informed about the state of long-term tasks and maintains a sense of momentum.

Collaborations and Requests

Effective communication also involves seeking help and coordinating with team members when needed.

"I need help with..."

This straightforward request for assistance is crucial for overcoming challenges quickly. For example, "I need help with debugging the new feature on the mobile app." Asking for help when needed ensures that issues are resolved efficiently and that you can continue making progress.
"Could someone assist me with..."

This polite request for help encourages team collaboration. For example, "Could someone assist me with setting up the CI/CD pipeline?" Encouraging collaboration fosters a supportive team environment where members feel comfortable seeking and offering assistance.
"I'm waiting for feedback from..."

This phrase helps you indicate dependencies on other team members. For example, "I'm waiting for feedback from the design team on the latest mockups." Communicating dependencies ensures that everyone is aware of what’s needed to move forward and can prioritize their work accordingly.

Next Steps

Outlining your next steps ensures that the team knows what you’ll be focusing on next, helping to maintain alignment and momentum.

"Next, I'll be..."

This phrase clearly indicates your upcoming tasks. For example, "Next, I'll be working on the API integration for the notifications system." Providing clear next steps helps the team understand your planned activities and how they align with the project’s goals.
"My next steps are..."

This variation helps you outline a series of upcoming tasks. For example, "My next steps are to finalize the database schema and start the data migration." Offering a roadmap of your next steps keeps the team informed about your planned progress and any upcoming milestones.
"I'll move on to..."

This phrase indicates a transition from one task to another. For example, "I'll move on to writing the unit tests for the new module." Communicating your transitions helps the team understand the flow of your work and how each task contributes to the overall project.

Best Practices for Stand-Up Meetings

While using the right phrases and sentences is crucial, adhering to some best practices can further enhance the effectiveness of your stand-up meetings.

Be Concise

Stand-up meetings are designed to be short and to the point. Aim to deliver your update in under two minutes, focusing on key information without unnecessary details. This helps keep the meeting efficient and respects everyone’s time.

Be Clear

Clarity is essential for effective communication. Use simple and direct language to convey your message. Avoid jargon or overly complex explanations that might confuse team members.

Stay Relevant

Ensure that your update is relevant to the team and the project. Share information that impacts the team’s work or the project’s progress. Avoid discussing unrelated topics that don’t contribute to the meeting’s purpose.

Be Honest

If you’re facing challenges or are behind schedule, be honest about it. Transparency helps the team address issues promptly and find solutions together. It’s better to acknowledge problems early on rather than let them escalate.

Encourage Engagement

Stand-up meetings should be interactive. Encourage team members to ask questions or offer assistance. Fostering an environment of open communication and collaboration strengthens the team dynamic.

Mastering the art of communication in daily stand-up meetings involves using specific phrases and sentences to clearly convey your status, plans, and any blockers. By practicing these techniques and adhering to best practices, you can enhance your communication skills, contribute more effectively to your team, and ensure the success of your projects. Effective stand-up meetings not only keep everyone informed but also foster a collaborative and supportive team environment, paving the way for successful project outcomes.

Unlock Cross-Micro-Frontend State Sharing!

Trinmar Boado — Mon, 18 Mar 2024 07:53:23 +0000

Sharing State Across Micro Frontends with MicroLocalStore

In modern web development, the micro-frontend architecture has gained popularity due to its modularity, scalability, and ability to develop large applications as a composition of smaller, independent applications. However, one of the challenges with this approach is sharing state across these micro-frontends in an efficient and secure way.

Enter MicroLocalStore, a lightweight JavaScript library that provides a shared local storage solution across different origins. In this article, we'll explore how to use MicroLocalStore to share state between micro-frontends, enabling seamless communication and state management.

What is MicroLocalStore?

MicroLocalStore is a JavaScript library that creates an isolated local storage for each instance, allowing you to store and retrieve data seamlessly across different origins. It's designed specifically for micro-frontend architectures, enabling different micro-apps to share state without conflicts.

With MicroLocalStore, you can easily manage state listeners, send and receive messages between parent and child windows, and more. It's compatible with both browser and Node.js environments.

Installation

You can install MicroLocalStore using npm:

npm install micro-local-store

Alternatively, you can use the unpkg CDN in your HTML file:

<script src="https://unpkg.com/micro-local-store"></script>

Usage

Let's dive into a simple example to understand how MicroLocalStore works.

Setting Up MicroLocalStore

First, we need to create a new instance of MicroLocalStore and provide a unique identifier and an array of allowed URLs that can share the store's state.

const store = new MicroLocalStore("myStore", [
  "https://example.com",
  "https://another-example.com",
]);

Setting and Getting State

You can set the state using the setState method, which will merge the new state with the existing state.

store.setState({ key: "value" });

To retrieve the current state, use the getState method.

const state = store.getState();

Listening for State Changes

MicroLocalStore allows you to listen for state changes by registering a listener function with the onChange method.

store.onChange((newState) => {
  console.log(newState);
});

You can remove a listener function by calling the offChange method.

store.offChange(listener);

Example: Sharing State Between Micro Frontends

Let's consider a scenario where we have two micro-frontends, App1.html and App2.html, hosted on the different domains (https://example.com, https://another-example.com). We want to share state between these two micro-frontends using MicroLocalStore.

App1.html

<!DOCTYPE html>
<html>
  <body>
    <button id="trigger">Trigger State Change</button>
    <div id="state"></div>

    <script src="https://unpkg.com/micro-local-store"></script>
    <script>
      const store = new MicroLocalStore("myStore", [
        "https://example.com/App1.html",
        "https://another-example.com/App2.html"
      ]);

      // Get state
      const state = store.getState();
      document.getElementById("state").innerHTML = JSON.stringify(state);

      // Listen for state changes
      store.onChange((newState) => {
        document.getElementById("state").innerHTML = JSON.stringify(newState);
      });

      // Set state on button click
      document.getElementById("trigger").addEventListener("click", () => {
        store.setState({ key: "value from App1" });
      });
    </script>
  </body>
</html>

App2.html

<!DOCTYPE html>
<html>
  <body>
    <button id="trigger">Trigger State Change</button>
    <div id="state"></div>

    <script src="https://unpkg.com/micro-local-store"></script>
    <script>
      const store = new MicroLocalStore("myStore", [
        "https://example.com/App1.html",
        "https://another-example.com/App2.html"
      ]);

      // Get state
      const state = store.getState();
      document.getElementById("state").innerHTML = JSON.stringify(state);

      // Listen for state changes
      store.onChange((newState) => {
        document.getElementById("state").innerHTML = JSON.stringify(newState);
      });

      // Set state on button click
      document.getElementById("trigger").addEventListener("click", () => {
        store.setState({ key: "value from App2" });
      });
    </script>
  </body>
</html>

In this example, both App1.html and App2.html create a new instance of MicroLocalStore with the same identifier ("myStore"). They also specify the URLs of the other micro-frontend that is allowed to share the state.

Each micro-frontend listens for state changes using the onChange method and updates its UI accordingly. When the "Trigger State Change" button is clicked, it sets a new state using the setState method, which will be reflected in both micro-frontends.

Cross-Origin Resource Sharing (CORS)

MicroLocalStore uses the postMessage API to communicate between different windows. This requires that the server hosting your application allows the URLs of the other applications to access your application. This is controlled by the server's CORS policy.

When creating a new MicroLocalStore instance, you must provide an array of URLs that are allowed to share the store's state. These URLs must be allowed by the server's CORS policy.

If you're using Express.js, you can use the cors middleware to set up your CORS policy. Here's an example:

const express = require("express");
const cors = require("cors");

const app = express();

const corsOptions = {
  origin: ["https://example.com", "https://another-example.com"],
};

app.use(cors(corsOptions));

// Your routes here

app.listen(3000, () => {
  console.log("Server is running on port 3000");
});

In this example, https://example.com and https://another-example.com are allowed to access your application.

Conclusion

MicroLocalStore provides a simple and efficient way to share state across micro-frontends, enabling seamless communication and state management. By creating an isolated local storage for each instance and allowing cross-origin communication, MicroLocalStore makes it easy to build modular and scalable web applications using the micro-frontend architecture.

Give MicroLocalStore a try in your next micro-frontend project and experience the power of shared state management across independent applications.

What I've Learned Transitioning to Private Sector as a Software Engineer

Trinmar Boado — Fri, 15 Mar 2024 08:29:14 +0000

After years working for the government, I made the move to the private sector. This career transition gave me a chance to seriously reflect on development practices and approaches. Here are some of the biggest lessons I realized:

Development Best Practices

Following good coding habits is crucial for keeping codebases healthy and extensible long-term. Nowadays, I prioritize:

Using TypeScript’s type system properly instead of excessive type castings like as. Using type guards provides stronger type safety:

interface User {
  name: string 
  email?: string
}

const validateEmail = (user: User) => {
  if ("email" in user) {
    // Type guard checks for optional 'email' prop
    console.log(user.email.toUpperCase())
  }
}

Checking for null/undefined explicitly with optional chaining instead of relying on non-null assertion operators like !:

const userName = user?.name ?? "Anon"
// Optional chaining handles null/undefined

Being smart about utility libraries like Lodash. They can make code more readable for complex operations, but watch out for bundle bloat.

I’ve also become way more aware of areas that create technical debt:

Avoiding nested data structures in databases, as they hurt queryability and make it harder to evolve data models cleanly.
Preventing tight coupling between application logic and the data model to reduce cascading changes when models update.
Establishing consistent code styles and patterns across the team for better readability and knowledge sharing.

Incorporating automated tests is another big realization, but with a pragmatic approach. Unit, integration, and end-to-end tests are all valuable, but I prioritize what really needs comprehensive test coverage.

Backend Architecture and TypeScript

On the backend, I’ve seen great benefits from TypeScript’s static type checking — especially with data transfer objects (DTOs). Defining DTOs with strict types upfront helps catch formatting issues early in requests/responses:

// Data Transfer Object 
interface CreateUserDTO {
  name: string
  email: string
  password: string
}

// Type-checked request body
const createUser = (req: Request<{}, {}, CreateUserDTO>) => {...}

That said, TypeScript has limits. Its type system mainly enforces compile-time safety, so extra runtime validation is still smart for handling sketchy or unpredictable data.

I’ve also solidified my preference for separating concerns on the server-side:

Using controllers strictly for routing/auth logic
Separate service layer for core business logic
Repository layer for database access

// Controller
export const getUserController = async (req: Request, res: Response) => {
  const user = await getUserService(req.params.id)
  res.json(user)
}

// Service
export const getUserService = async (id: string) => {
  const user = await userRepository.findById(id)
  // ...business logic
  return user
}

// Repository 
export const userRepository = {
  findById: (id: string) => { /* DB query */ }
}

Databases

My experience has only reinforced that SQL’s tabular relational model is better than NoSQL’s nested data approach for most applications.

While NoSQL’s flexibility to evolve schemas easily is appealing early on, those advantages get outweighed by drawbacks around query efficiency and performance at scale. Normalized data models, leveraging database relationships and SQL’s powerful querying, provide a sturdier long-term foundation.

{
  "_id": "pr_001",
  "name": "Product 1", 
  "categories": ["Electronics", "Computers"],
  "specs": {
    "weight": 2.5,
    "dimensions": {
      "length": 12,
      "width": 8,
      "height": 3
    }
  },
  "variants": [
    { "id": "pr_001_red", "color": "red" },
    { "id": "pr_001_blu", "color": "blue" }
  ]
}

While this flexible schema is convenient during initial development, it becomes increasingly problematic over time:

Querying across products and variants requires complex join-like operations
Updating nested specs or adding new variant properties is cumbersome
Aggregating and analyzing catalog data is inefficient

In a normalized SQL schema, the same product data could be split into separate tables like:

Products (id, name, weight)
Categories (id, name)
Product_Categories (product_id, category_id)
Specs (product_id, length, width, height)
Variants (id, product_id, color)

This separation allows queries like “Get all products under 3 lbs with variant colors” to be executed efficiently using JOINs. New properties can be added seamlessly, and analyzing the catalog data is much simpler with SQL’s advanced querying capabilities.

So while NoSQL’s flexible schema provides early convenience, the long-term sustainability and performance advantages of SQL’s relational model become increasingly evident over time.

Frontend Development

For frontend architecture, I’ve looked at the tradeoffs between micro-frontends and monolithic frontends:

Micro-Frontends

Independent deployment
Gradual framework updates
Limit regression risks
But increases complexity

Monolithic Frontend

Simpler, fewer duplicates
Easier to bundle/deploy
Makes sense for low-complexity
Can inhibit large-scale evolution

I’ve also got tons of experience with both Vue.js and React recently. While React’s huge ecosystem and adoption are clear pros, I prefer Vue’s coherent reactivity model and separation of concerns between script, template, and styles:

<template>
  <div>{{ upperCaseName }}</div>
</template>

<script setup>
import { computed } from 'vue'

const props = defineProps({
  name: String
})

const upperCaseName = computed(() => props.name.toUpperCase())
</script>

In my experience, Vue provides an easier entry point for rapid development, while its opinionated state management, watchers, and computed properties help avoid subtle bugs. With TypeScript, React’s hooks paradigm can get overly complex compared to Vue’s more straightforward reactivity.

Project Management

From an execution standpoint, I’ve gained a greater appreciation for diligent ticket grooming and documentation. Well-defined tickets capturing clear requirements, repro steps, and user narratives promote shared understanding and productive collaboration.

Bug Ticket Template:

🐞 Summary Description:

Profile Image Upload Failing

Description:

When attempting to upload a new profile image from the Settings page, the upload fails with an error alert.

👣 Steps to Reproduce:

Go to Profile Settings page
Click “Upload New Image”
Select an image file
Click “Save Changes”

🚫 Actual Result:

Error alert “Upload Failed” is displayed and existing profile image remains.

✅ Expected Result:

New image is displayed and replaces the existing profile image.

Task Ticket Template:

📖 Description:

In order to improve product page experience 🎯, as a front-end developer 👨‍💻, I need to add an image zoom feature when clicking product images ✅.

✅ Acceptance Criteria:

User can click thumbnail to zoom
Overlay displays zoomed image
User can move and resize overlay
Overlay hides when clicking off

📋 Other Information

Attach Figma designs for zoom overlay styles/interactions.

Breaking down larger efforts into granular sub-tasks with estimations helps manage stakeholder expectations and workloads. Working off vague or thinly-documented tickets inevitably leads to misalignment and rework later.
I've also refined my perspective on strategic debugging workflows. While IDE debuggers with breakpoints are powerful, well-placed console.log()statements remain invaluable - especially for analyzing production issues or reasoning about async behavior.

Looking Ahead

Since transitioning to the private sector, all these lessons around best practices, architectural patterns, technology tradeoffs, and processes have crystallized for me. But I recognize this industry moves rapidly, so any rigid dogma will become obsolete quick.
I aim to keep an open, growth mindset - continuously re-evaluating approaches while pragmatically applying techniques that fit the current context best. This intentional reflection period has reinvigorated my passion while giving me a refined, balanced perspective on full-stack development.

Data Transformation Magic: Simplify Complex Data with Remap.JS!

Trinmar Boado — Fri, 03 Nov 2023 14:59:30 +0000

Data mapping can be a challenging and complex task, especially when dealing with nested data structures, arrays, and deeply nested objects. In scenarios where you need to restructure or transform data from one format to another, the complexity can quickly become overwhelming. This is where the Remap.JS library comes to the rescue.

https://www.npmjs.com/package/@trinly01/remap.js

Remap.JS Library Tutorial

The Remap.JS library is a versatile JavaScript utility that simplifies data transformation, making it suitable for a wide range of use cases. In this tutorial, we'll explore how to use the library to remap and notate data, allowing you to transform complex data structures easily.

Installation
Remap Function
Notate Function
Tutorial Example

Installation

To get started with the Remap.JS library, you'll need to install it into your project. You can install it using npm or yarn:

npm install @trinly01/remap.js
# or
yarn add @trinly01/remap.js

Once the library is installed, you can import it into your JavaScript file.

import { remap, notate } from '@trinly01/remap.js';

Remap Function

The remap function allows you to transform an array of objects into a new array with the mapped data according to the specified key mapping configuration. It's a powerful tool for simplifying complex data structures.

Usage:

const transformedData = remap(sourceArray, keyMap);

sourceArray (Array): The array of source objects to remap.
keyMap (Object): The key mapping configuration defining how to map the source data to the destination object.

Notate Function

The notate function is used to create and assign values to objects with specific key notations. It's highly flexible and adaptable for various use cases.

Usage:

notate(notation, value, result);

notation (String or Object): The key notation in the destination object. If it's an object, you can set multiple values at once. If it's a single path notation (string), the value parameter is required.
value (Any): The value to assign to the destination object. Required when notation is a single path notation (string).
result (Object, optional): The result object where the data will be assigned.

Tutorial Example

Let's put the Remap.JS library to use with a simple example:

import { remap, notate } from '@trinly01/remap.js';

const sourceArray = [
  {
    id: 1,
    name: 'John Doe',
    contact: {
      email: 'john@work.com',
      phone: '123-456-7890',
    },
  },
  // Add more source data objects here
];

const keyMap = {
  'Profile.id': 'id',
  'Profile.name': 'name',
  'Profile.email': 'contact.email',
  'Profile.phone': 'contact.phone',
};

// Remap the source data
const transformedData = remap(sourceArray, keyMap);

console.log('Transformed Data:\n', transformedData);

// Notate single values
const result = {};
notate('Profile.id', 1, result);
notate('Profile.name', 'John Doe', result);
notate('Profile.email', 'john@work.com', result);
notate('Profile.phone', '123-456-7890', result);

console.log('Result after notating single values:\n', result);

// Notate multiple values using an object
const obj = {};
const multipleValues = {
  'Profile.id': 1,
  'Profile.name': 'John Doe',
  'Profile.email': 'john@work.com',
  'Profile.phone': '123-456-7890',
};

notate(multipleValues, obj);

console.log('Result after notating multiple values:\n', obj);

This example demonstrates how to use the Remap.JS library to remap and notate data, making data transformation tasks simpler and more flexible.

That's it! You've learned how to use the Remap.JS library to streamline data transformation and notating. This versatile utility can be a valuable asset in various data manipulation tasks.

Big-O Notation

Trinmar Boado — Thu, 07 Sep 2023 13:17:11 +0000

Sure! Big O notation is used to describe the time complexity of algorithms. In JavaScript, various algorithms may exhibit different time complexities. Here are some examples with explanations:

Constant Time O(1):

function constantTimeExample(arr) {
    return arr[0]; // Accessing the first element in the array, regardless of the array size, takes constant time.
}

Linear Time O(n):

function linearTimeExample(arr) {
    for (let i = 0; i < arr.length; i++) {
        console.log(arr[i]); // The function loops through the entire array, and the running time grows linearly with the array size.
    }
}

Quadratic Time O(n^2):

function quadraticTimeExample(arr) {
    for (let i = 0; i < arr.length; i++) {
        for (let j = 0; j < arr.length; j++) {
            console.log(arr[i], arr[j]); // Nested loops make the function run n^2 times, where n is the array size.
        }
    }
}

Logarithmic Time O(log n):

function binarySearch(arr, target) {
    let left = 0;
    let right = arr.length - 1;

    while (left <= right) {
        const mid = Math.floor((left + right) / 2);
        if (arr[mid] === target) return mid;
        if (arr[mid] < target) left = mid + 1;
        else right = mid - 1;
    }

    return -1;
}
// In a binary search, the search space is divided in half at each step, making it logarithmic time complexity.

Polynomial Time O(n^k):

function polynomialTimeExample(arr) {
    for (let i = 0; i < arr.length; i++) {
        for (let j = 0; j < arr.length; j++) {
            for (let k = 0; k < arr.length; k++) {
                console.log(arr[i], arr[j], arr[k]); // Triple nested loop makes the function run n^3 times, where n is the array size.
            }
        }
    }
}

These examples demonstrate how Big O notation helps us understand how the performance of an algorithm changes as the size of the input data increases. It allows us to analyze and compare different algorithms to choose the most efficient one for a particular problem.

Time Complexity and Space Complexity are two fundamental concepts in computer science that help analyze the efficiency and resource usage of algorithms and data structures. Let's delve into these concepts with JavaScript examples:

1. Time Complexity:
Time complexity measures how the running time of an algorithm or function scales with the input size. It provides an estimate of the number of basic operations (e.g., comparisons, assignments) an algorithm requires to complete its task, as a function of the input size. Common time complexities are denoted using Big O notation (e.g., O(1), O(n), O(n^2)).

Examples:

Constant Time O(1):

  function constantTimeExample(arr) {
      return arr[0]; // Regardless of the array size, accessing the first element takes constant time.
  }

Linear Time O(n):

  function linearTimeExample(arr) {
      for (let i = 0; i < arr.length; i++) {
          console.log(arr[i]); // The function loops through the entire array, taking time proportional to 'n', the array size.
      }
  }

Quadratic Time O(n^2):

  function quadraticTimeExample(arr) {
      for (let i = 0; i < arr.length; i++) {
          for (let j = 0; j < arr.length; j++) {
              console.log(arr[i], arr[j]); // Double nested loop makes the function run 'n' times for each 'n' element, resulting in 'n^2' time complexity.
          }
      }
  }

2. Space Complexity:
Space complexity measures the amount of memory an algorithm uses with respect to the input size. It's concerned with the growth of memory usage as the input size increases. Similar to time complexity, space complexity is also represented using Big O notation.

Examples:

Constant Space O(1):

  function constantSpaceExample(n) {
      let result = 0;
      for (let i = 0; i < n; i++) {
          result += i; // The 'result' variable consumes a fixed amount of memory, regardless of 'n'.
      }
      return result;
  }

Linear Space O(n):

  function linearSpaceExample(n) {
      let arr = [];
      for (let i = 0; i < n; i++) {
          arr.push(i); // The 'arr' array grows linearly with 'n', leading to linear space complexity.
      }
      return arr;
  }

Quadratic Space O(n^2):

  function quadraticSpaceExample(n) {
      let matrix = [];
      for (let i = 0; i < n; i++) {
          matrix.push(Array(n).fill(0)); // Creating a 2D matrix with 'n' rows and 'n' columns leads to quadratic space complexity.
      }
      return matrix;
  }

Understanding time and space complexity is crucial for designing efficient algorithms and data structures, as it helps in making informed choices about which algorithm to use for a given problem and how it will perform as the input size grows.

Deploying Node.js App

Trinmar Boado — Thu, 27 Jul 2023 07:52:47 +0000

Below is a table comparing how to deploy a Node.js app on AWS, GCP, and Azure, along with some of the best services to use for each platform:

Service	AWS	GCP	Azure	Steps on Setting Up
Compute Service	Amazon EC2	Google Compute Engine (GCE)	Azure Virtual Machines (VMs)	1. Create a virtual machine instance (EC2) 2. Set up Node.js on the instance
Serverless	AWS Lambda	Google Cloud Functions	Azure Functions	1. Create a serverless function 2. Package and deploy your Node.js app
Container Orchestration	Amazon ECS or EKS	Google Kubernetes Engine (GKE)	Azure Kubernetes Service (AKS)	1. Create a container cluster 2. Deploy your Node.js app using Kubernetes manifests
App Platform	AWS Elastic Beanstalk	Google App Engine	Azure App Service	1. Create an app environment 2. Deploy your Node.js app to the platform
Database	Amazon RDS or DynamoDB	Google Cloud SQL or Firestore	Azure SQL Database or Cosmos DB	1. Create a database instance 2. Connect and deploy your Node.js app
File Storage	Amazon S3 or EFS	Google Cloud Storage	Azure Blob Storage	1. Create a storage bucket/container 2. Upload your app's files
Networking	Amazon VPC	Google Virtual Private Cloud (VPC)	Azure Virtual Network	1. Set up a virtual network 2. Configure network rules for your app
Load Balancing	Amazon ELB or ALB	Google Cloud Load Balancing	Azure Load Balancer or Application Gateway	1. Create a load balancer 2. Add your app instances to the balancer
Monitoring	Amazon CloudWatch	Google Cloud Monitoring	Azure Monitor	1. Set up monitoring for your app 2. Configure alerting and logs

These steps are simplified overviews of the process and may involve more specific configurations depending on your application's needs and the cloud provider's UI/CLI/API. Always refer to the official documentation of the respective cloud provider for detailed and up-to-date instructions.

graph TB
    subgraph Users
        user1[User 1]
        user2[User 2]
        user3[User 3]
    end

    subgraph Frontend
        vue1[Vue Client 1]
        vue2[Vue Client 2]
        vue3[Vue Client 3]
    end

    subgraph AWS
        subgraph Networking
            vpc[VPC]
            ig[Internet Gateway]
            rt[Route Tables]
            nat[NAT Gateway]
            subnet1[Public Subnet]
            subnet2[Private Subnet]
        end

        subgraph Compute
            elb[Elastic Load Balancing]
            asg[Auto Scaling Group]
            ec2_1[EC2 Instance 1]
            ec2_2[EC2 Instance 2]
            ec2_3[EC2 Instance 3]
        end

        subgraph Storage
            s3[S3 Bucket]
            efs[EFS]
        end

        subgraph Database
            db[Amazon RDS or DynamoDB]
            elasticache[ElastiCache]
        end

        subgraph Messaging
            sns[Amazon SNS]
            sqs[Amazon SQS]
        end

        subgraph Realtime
            apigw[API Gateway]
            lambda[AWS Lambda]
            iot[AWS IoT Core]
        end

        subgraph Security
            iam[IAM]
            waf[WAF]
        end

        subgraph Deployment
            cicd[CI/CD Pipeline]
        end

        subgraph Monitoring
            cloudwatch[CloudWatch]
            xray[AWS X-Ray]
        end
    end

    user1 -.- vue1
    user2 -.- vue2
    user3 -.- vue3

    vue1 --> elb
    vue2 --> elb
    vue3 --> elb

    elb --> asg
    asg --> ec2_1
    asg --> ec2_2
    asg --> ec2_3

    ec2_1 --> db
    ec2_2 --> db
    ec2_3 --> db

    ec2_1 --> elasticache
    ec2_2 --> elasticache
    ec2_3 --> elasticache

    ec2_1 --> efs
    ec2_2 --> efs
    ec2_3 --> efs

    ec2_1 --> s3
    ec2_2 --> s3
    ec2_3 --> s3

    ec2_1 --> sns
    ec2_2 --> sns
    ec2_3 --> sns

    sns --> sqs
    sqs --> lambda
    lambda --> iot

    iot --> vue1
    iot --> vue2
    iot --> vue3

    apigw --> lambda
    apigw --> waf

    cicd -.-> ec2_1
    cicd -.-> ec2_2
    cicd -.-> ec2_3

    iam -.-> ec2_1
    iam -.-> ec2_2
    iam -.-> ec2_3
    iam -.-> lambda
    iam -.-> iot
    iam -.-> apigw

    cloudwatch -.-> vpc
    cloudwatch -.-> ec2_1
    cloudwatch -.-> ec2_2
    cloudwatch -.-> ec2_3
    cloudwatch -.-> elb
    cloudwatch -.-> asg
    cloudwatch -.-> db
    cloudwatch -.-> elasticache
    cloudwatch -.-> s3
    cloudwatch -.-> efs
    cloudwatch -.-> sns
    cloudwatch -.-> sqs
    cloudwatch -.-> lambda
    cloudwatch -.-> iot
    cloudwatch -.-> apigw
    cloudwatch -.-> waf
    cloudwatch -.-> cicd

    xray -.-> ec2_1
    xray -.-> ec2_2
    xray -.-> ec2_3
    xray -.-> lambda
    xray -.-> apigw

    classDef boxStyle stroke:#000,stroke-width:2px,color:#000,fill:#bbb;
    class Users,Frontend boxStyle

Here's an explanation of the improved architecture diagram:

Frontend:

The frontend is built using Vue.js, with separate Vue client applications for each user.
The Vue clients communicate with the backend API through the Elastic Load Balancing and receive real-time updates through AWS IoT Core.

Backend:

The backend is implemented using Node.js, running on EC2 instances managed by an Auto Scaling Group.
The Node.js backend communicates with the database (Amazon RDS or DynamoDB) for storing and retrieving chat messages, user information, channels, and other persistent data.
The Node.js backend also interacts with Amazon S3 for storing and serving static assets, such as images and files shared within the chat system.
The Node.js backend publishes real-time updates to Amazon SNS, which triggers AWS Lambda functions for broadcasting messages to connected clients via AWS IoT Core.
API Gateway and Lambda functions can be used for additional functionality, such as creating channels, managing groups, and other operations.
The backend instances can access shared file storage through Amazon Elastic File System (EFS).
Frequently accessed data can be cached using Amazon ElastiCache for improved performance.

Networking:

The entire architecture is hosted within an AWS Virtual Private Cloud (VPC) for isolation and security.
Public and private subnets are created, with the public subnet hosting the Elastic Load Balancing and the private subnet hosting the EC2 instances and other services.
An Internet Gateway is attached to the VPC to allow internet access.
A NAT Gateway is used to enable EC2 instances in the private subnet to access the internet for updates and other outbound traffic.
Route Tables are configured to route traffic appropriately.

Compute:

Elastic Load Balancing distributes incoming traffic across multiple EC2 instances, ensuring high availability and scalability.
An Auto Scaling Group is used to automatically scale the number of EC2 instances based on demand, ensuring the system can handle increased traffic.

Storage:

Amazon S3 (Simple Storage Service) is used for storing and serving static assets, such as images and files shared within the chat system.
Amazon Elastic File System (EFS) provides shared file storage across EC2 instances.

Database:

Amazon RDS (Relational Database Service) or DynamoDB (NoSQL database) can be used to store chat messages, user information, channels, and other persistent data.
Amazon ElastiCache is used for caching frequently accessed data, improving performance.

Messaging:

Amazon SNS (Simple Notification Service) and SQS (Simple Queue Service) are used for asynchronous communication and decoupling components.
SNS publishes messages to SQS, which triggers AWS Lambda functions for real-time processing and broadcasting messages to connected clients.

Real-time Communication:

AWS IoT Core is used for real-time bi-directional communication between the server and clients, enabling real-time chat and file sharing.
API Gateway and Lambda functions can be used for additional real-time functionality, such as creating channels, managing groups, and other operations.

Security:

AWS Identity and Access Management (IAM) is used for controlling access to AWS resources, ensuring secure access to the EC2 instances, Lambda functions, IoT Core, and API Gateway.
AWS Web Application Firewall (WAF) protects the API Gateway from common web exploits and malicious traffic, enhancing the security of the application.

Deployment:

A Continuous Integration/Continuous Deployment (CI/CD) Pipeline is used for automated building, testing, and deploying the application to the EC2 instances.

Monitoring:

Amazon CloudWatch is used for monitoring the entire infrastructure, including EC2 instances, load balancers, databases, and other services, providing insights into performance, errors, and resource utilization.
AWS X-Ray is used for debugging and analyzing the performance of the application and its underlying services, helping identify and troubleshoot issues.

This improved architecture leverages various AWS services to provide a scalable, highly available, secure, and fault-tolerant real-time chat system. It addresses aspects such as caching, file storage, security, deployment, and monitoring, ensuring a robust and efficient solution. The architecture remains modular and extensible, allowing for future enhancements and integrations with other AWS services as needed.

Note: The specific configurations and implementation details for each service would need to be tailored based on the project's requirements, security considerations, and best practices.

My Coding Challenge Interview! Sheesh!

Trinmar Boado — Thu, 20 Jul 2023 15:34:59 +0000

I am very happy I made it!

/*
You are working on an authentication system and there is a set of rules the users have to follow when picking a new password:

1. It has to be at least 16 characters long.
2. The password cannot contain the word "password". This rule is not case-sensitive.
3. The same character cannot be used more than 4 times. This rule is case-sensitive, "a" and "A" are different characters.
4. The password has to contain at least one uppercase and one lowercase letter.
5. The password has to contain at least one of the following special characters "*","#","@".

Write a function that takes in a password and returns a collection of any rule numbers that are not met.

password_1 = "Strongpwd9999#abc"             ==> []
password_2 = "Less10#"                       ==> [1]
password_3 = "Password@"                     ==> [1,2]
password_4 = "#PassWord011111112222223x"     ==> [2,3]
password_5 = "password#1111111"              ==> [2,3,4]
password_6 = "aaaapassword$$"                ==> [1,2,3,4,5]
password_7 = "LESS10#"                       ==> [1,4]
password_8 = "SsSSSt#passWord"               ==> [1,2]


All test cases:

validate(password_1) ==> []
validate(password_2) ==> [1]
validate(password_3) ==> [1,2]
validate(password_4) ==> [2,3]
validate(password_5) ==> [2,3,4]
validate(password_6) ==> [1,2,3,4,5]
validate(password_7) ==> [1,4]
validate(password_8) ==> [1,2]


Complexity variables:

N = length of the password

time O(n)
space O()

 */

"use strict";


const password_1 = "Strongpwd9999#abc";
const password_2 = "Less10#";
const password_3 = "Password@";
const password_4 = "#PassWord011111112222223x";
const password_5 = "password#1111111";
const password_6 = "aaaapassword$$";
const password_7 = "LESS10#";
const password_8 = "SsSSSt#passWord";







function validate(password) {
  const arrRules = [] 

  // 1. It has to be at least 16 characters long.
  if (password.length < 16) arrRules.push(1)

  // 2. The password cannot contain the word "password". This rule is not case-sensitive.
  if (password.toLowerCase().includes('password')) arrRules.push(2)


  // 3. The same character cannot be used more than 4 times. This rule is case-sensitive, "a" and "A" are different characters.
  const charCounter = {}

  for (const char of password) {
    if (charCounter[char]) {
      charCounter[char] ++ 
    } else {
      charCounter[char] = 1
    }

    if (charCounter[char] > 4) {
      arrRules.push(3)
      break
    }
  }



  // 4. The password has to contain at least one uppercase and one lowercase letter.
  let hasUpperCase = false
  let hasLowerCase = false

  for (const char of password) {
    const decCode = char.charCodeAt(0) 

    if (decCode > 64 && decCode < 91) {
      hasUpperCase = true
    } else if (decCode > 96 && decCode < 123) {
      hasLowerCase = true
    }

    if (hasUpperCase && hasLowerCase) break
  }

  if (!(hasUpperCase && hasLowerCase)) {
    arrRules.push(4)
  }

  // 5. The password has to contain at least one of the following special characters "*","#","@".

  let hasSpecialChar = false

  for (const char of password) {

    if (["*","#","@"].includes(char)) {
      hasSpecialChar = true
      break
    }

  }

  if (!hasSpecialChar) arrRules.push(5)

  return arrRules

}

console.log(validate(password_1))
console.log(validate(password_2))
console.log(validate(password_3))
console.log(validate(password_4))
console.log(validate(password_5))
console.log(validate(password_6))
console.log(validate(password_7))
console.log(validate(password_8))