32 KiB

Raw Blame History

TODO: Test App Native Fetcher Improvements

Created: 2025-10-31
Updated: 2025-10-31 (implementation complete: ES256K JWT generation and network security config)
Context: Review of TestNativeFetcher.java implementation for endorser API integration
Status: ✅ IMPLEMENTATION COMPLETE - All high-priority items complete. Item #1 (ES256K JWT generation) implemented using did-jwt and ethers. Item #15 (Network Security Config) created. All TypeScript/Java interfaces updated. Plugin rebuilt with updated definitions.

📊 Progress Summary

✅ Completed High-Priority Items

Item #1: JWT Algorithm Investigation - ✅ COMPLETE (ES256K requirement confirmed, implementation pending)
Item #2: SharedPreferences Persistence - ✅ COMPLETE
Item #3: Error Handling and Retry Logic - ✅ COMPLETE
Item #6: Context Management - ✅ COMPLETE

✅ Critical Implementation Complete (Item #1)

ES256K JWT Token Generation - ✅ COMPLETE: Implemented generateEndorserJWT() function using did-jwt and ethers libraries. Generates proper ES256K signed JWTs from test user zero's seed phrase. Native fetcher now receives pre-generated tokens, avoiding Java DID library complexity.

🟡 Medium Priority Status

Item #4: API Response Structure Validation - ✅ VERIFIED (structure verified, validation improvements needed - see details below)
Item #5: Comprehensive Logging - Partial (basic logging exists, more comprehensive needed)

🟢 Low Priority

Items #7-11: All pending

📝 Configuration Tasks

Item #13: Real API Calls - Ready (can now enable localhost mode, ES256K JWT generation complete)
Item #14: TypeScript Types - ✅ COMPLETE (plugin rebuilt, types updated, as any removed)
Item #15: Network Security Config - ✅ COMPLETE (config created, AndroidManifest updated)

🔴 High Priority

1. ⚠️ JWT Generation and Verification Status

JWT Generation: ✅ COMPLETE - TypeScript generates ES256K signed JWTs correctly
JWT Verification: 🟡 PARTIAL - Generation works, but server verification fails

Current Status (2025-10-31):

✅ JWT Generation (TypeScript):

Using did-jwt library with ES256K algorithm ✓
Signing with Ethereum private key from seed phrase ✓
Correct payload structure (iat, exp, iss, sub, aud) ✓
Location: test-user-zero.ts → generateEndorserJWT()

🟡 JWT Verification Issue:

Error: JWT failed verification: Error: invalid_signature: no matching public key found
Root Cause: Server cannot resolve DID to get public key for signature verification
Server uses: didJwt.verifyJWT(jwt, {resolver}) which requires DID resolution
The JWT signature is cryptographically valid, but server can't verify it

Problem: DID did:ethr:0x0000694B58C2cC69658993A90D3840C560f2F51F may not be:

Registered on the resolver/blockchain that the server uses
Accessible by the server's DID resolver
Configured correctly in the test API server

Next Steps (to be verified):

Verify DID registration: Ensure User Zero's DID is registered on resolver server uses
Test with known DID: Try a DID that definitely exists in server's system
Check server resolver config: Verify server's DID resolver can resolve did:ethr: DIDs
Check test API server: If using localhost:3000, confirm it supports DID-based JWT verification

Verification Status Table:

Component	Status	Notes
JWT Algorithm	✅ Correct	ES256K (matches server expectation)
JWT Format	✅ Correct	Proper structure and claims
JWT Signature	✅ Valid	Signature is cryptographically valid
DID Resolution	❌ Failing	Server can't resolve DID to public key
Overall Status	🟡 Partial	Generation works; verification fails due to DID resolution

Investigation Results (See INVESTIGATION_JWT_ALGORITHM_RESULTS.md for full details):

✅ CONFIRMED: Endorser-ch API uses DID-based JWTs (ES256K), NOT HMAC-SHA256.

TimeSafari Implementation (~/projects/timesafari/crowd-funder-for-time-pwa/src/libs/crypto/vc/index.ts):

Uses did-jwt.createJWT() with SimpleSigner(privateKeyHex)
Signs with Ethereum private key from DID identity
Algorithm: ES256K (default for did-jwt library)

endorser-ch Verification (~/projects/timesafari/endorser-ch/src/api/services/vc/index.js):

Uses did-jwt.verifyJWT(jwt, {resolver}) for verification
Verifies signature using DID resolver (resolves DID to public key)
NO shared secret used - authentication is DID-based

✅ IMPLEMENTATION COMPLETE:

TypeScript generates ES256K signed JWTs using generateEndorserJWT()
Native fetcher receives pre-generated JWT token via configureNativeFetcher()
No Java DID library needed - token generated in TypeScript with did-jwt library

Current Architecture:

TypeScript: generateEndorserJWT() → Creates ES256K signed JWT
TypeScript: DailyNotification.configureNativeFetcher({ jwtToken }) → Passes token to native
Android: TestNativeFetcher.configure() → Stores JWT token
Android: Background worker uses stored JWT token for API requests

Remaining Issue: DID resolution on server side (see verification status above)

Previous Implementation (REMOVED):

~~HMAC-SHA256 with shared secret~~ → Replaced with ES256K DID-based
~~Java DID library implementation~~ → Not needed (TypeScript generates token)

Implementation Options (NO LONGER NEEDED - TypeScript handles it):

~~Option 1: Use did-jwt-java Library (Recommended)~~

// DEPRECATED - TypeScript generates JWT now
// No longer needed in Java code

~~Option 2: Use web3j for Ethereum Signing~~

// DEPRECATED - TypeScript generates JWT now
// No longer needed in Java code
    keyPair
);
// Then encode signature according to ES256K format for JWT

References:

Investigation Results: See INVESTIGATION_JWT_ALGORITHM_RESULTS.md for complete findings
TimeSafari Implementation: ~/projects/timesafari/crowd-funder-for-time-pwa/src/libs/crypto/vc/index.ts - createEndorserJwtForKey() function
endorser-ch Verification: ~/projects/timesafari/endorser-ch/src/api/services/vc/index.js - decodeAndVerifyJwt() function
did-jwt library - DID-based JWT library (JavaScript reference)
did-jwt-java - Java implementation (if available) or alternative Java DID libraries

Impact: CRITICAL - Current HMAC-SHA256 implementation will be rejected by API server. All authentication will fail until DID-based ES256K signing is implemented.

✅ ARCHITECTURAL DECISION: Generate JWT in TypeScript (host app), pass token to native fetcher

Rationale:

TimeSafari already has did-jwt library available in TypeScript
TimeSafari can access DID private keys via Capacitor SQLite (retrieveFullyDecryptedAccount())
Plugin SPI pattern is designed for host app to provide implementations
Avoids complexity of finding/implementing Java DID libraries
Keeps cryptography in TypeScript where libraries are mature

Updated Implementation Approach:

Option A: Generate JWT in TypeScript, Pass Token (RECOMMENDED)

// In HomeView.vue or TimeSafari app
import { createEndorserJwtForDid } from '@/libs/endorserServer';

// Generate JWT in TypeScript using existing TimeSafari infrastructure
const account = await retrieveFullyDecryptedAccount(activeDid);
const jwtToken = await createEndorserJwtForDid(activeDid, {
  exp: Math.floor(Date.now() / 1000) + 60,
  iat: Math.floor(Date.now() / 1000),
  iss: activeDid
});

// Pass JWT token to native fetcher (no private key needed)
await DailyNotification.configureNativeFetcher({
  apiBaseUrl: 'http://10.0.2.2:3000',
  activeDid: activeDid,
  jwtToken: jwtToken  // Pre-generated token, not secret
});

// In TestNativeFetcher.java - Just use the token, don't generate it
private volatile String jwtToken; // Pre-generated token from TypeScript

public void configure(String apiBaseUrl, String activeDid, String jwtToken) {
    this.apiBaseUrl = apiBaseUrl;
    this.activeDid = activeDid;
    this.jwtToken = jwtToken; // Use pre-generated token
}

private String getAuthorizationHeader() {
    return "Bearer " + jwtToken;
}

Benefits:

✅ No Java DID library needed
✅ Uses existing TimeSafari infrastructure (did-jwt, retrieveFullyDecryptedAccount)
✅ Keeps cryptography in TypeScript (where it's proven to work)
✅ Native fetcher just uses token (simple, no crypto complexity)
✅ Token can be refreshed in TypeScript when needed

Next Actions:

Update configureNativeFetcher() TypeScript signature to accept jwtToken instead of jwtSecret
Update Java configureNativeFetcher() to accept jwtToken parameter
Remove JWT generation code from TestNativeFetcher.generateJWTToken()
Use pre-generated token in getAuthorizationHeader() method
Update HomeView.vue to generate JWT using TimeSafari's createEndorserJwtForDid()
For TimeSafari integration: Generate JWT in host app using account data from SQLite
Test with real endorser-ch API to verify tokens are accepted

Testing:

✅ Verified algorithm with endorser-ch source code - ES256K confirmed
✅ Generate JWT in TypeScript using did-jwt library (ES256K signing)
✅ Pass pre-generated JWT token to native fetcher via configureNativeFetcher()
⚠️ Verify tokens are accepted by the endorser API endpoint (pending real API testing)
Implement token refresh mechanism in TypeScript when tokens expire (60 seconds)

Implementation Checklist:

1. Update TypeScript Interface (src/definitions.ts):

✅ Change jwtSecret: string → jwtToken: string in configureNativeFetcher() signature
✅ Update JSDoc to reflect that token is pre-generated, not a secret
✅ Rebuild plugin to update dist/definitions.d.ts

2. Update Java Plugin (android/plugin/.../DailyNotificationPlugin.java):

✅ Change String jwtSecret = call.getString("jwtSecret") → String jwtToken = call.getString("jwtToken")
✅ Update validation message: "Missing required parameters: apiBaseUrl, activeDid, and jwtToken are required"
✅ Update fetcher.configure(apiBaseUrl, activeDid, jwtToken) call
✅ Update Javadoc to reflect token-based approach

3. Update Native Interface (android/plugin/.../NativeNotificationContentFetcher.java):

✅ Change default void configure(String apiBaseUrl, String activeDid, String jwtSecret) → default void configure(String apiBaseUrl, String activeDid, String jwtToken)
✅ Update Javadoc to explain token is pre-generated by TypeScript

4. Update TestNativeFetcher (test-apps/.../TestNativeFetcher.java):

✅ Change private volatile String jwtSecret; → private volatile String jwtToken;
✅ Update configure() method signature and implementation
✅ Remove entire generateJWTToken() method (HMAC-SHA256 implementation removed)
✅ Update fetchContentWithRetry() to use jwtToken directly
✅ Remove JWT-related constants (JWT_EXPIRATION_MINUTES) - no longer needed
✅ Remove HMAC-SHA256 imports (Mac, SecretKeySpec, Base64, MessageDigest) - not used elsewhere

5. Update HomeView.vue (test-apps/.../HomeView.vue):

✅ Implement ES256K JWT generation using did-jwt and ethers libraries
✅ Generate JWT before calling configureNativeFetcher() using generateEndorserJWT()
✅ Update configureNativeFetcher() call to use jwtToken instead of jwtSecret
✅ Remove as any type assertion after plugin rebuild

6. ES256K JWT Generation Implementation (test-apps/.../test-user-zero.ts):

✅ Add did-jwt@^7.0.0 and ethers@^6.0.0 dependencies
✅ Implement generateEndorserJWT() function:
- Derives Ethereum private key from seed phrase using ethers.HDNodeWallet
- Uses did-jwt.SimpleSigner for ES256K signing
- Creates proper ES256K signed JWTs matching TimeSafari's pattern
✅ Export generateEndorserJWT for use in HomeView.vue

6. For TimeSafari Production Integration:

In TimeSafari app, generate JWT using createEndorserJwtForKey() with account from SQLite
Call DailyNotification.configureNativeFetcher() with generated token
Implement token refresh logic when tokens expire (60 seconds)
Handle token expiration errors and regenerate tokens

7. Documentation Updates:

Update docs/NATIVE_FETCHER_CONFIGURATION.md to reflect token-based approach
Document how to generate tokens in TypeScript using TimeSafari infrastructure
Remove references to jwtSecret and HMAC-SHA256

2. Implement SharedPreferences Persistence for Configuration

Status: ✅ COMPLETE

Current State: ✅ Implemented - getStarredPlanIds() and getLastAcknowledgedJwtId() use SharedPreferences

Location: TestNativeFetcher.java → getStarredPlanIds(), getLastAcknowledgedJwtId()

Implementation Status: ✅ COMPLETE

✅ SharedPreferences initialized in constructor with PREFS_NAME = "DailyNotificationPrefs"
✅ getStarredPlanIds() - Loads JSON array from SharedPreferences
✅ getLastAcknowledgedJwtId() - Loads JWT ID from SharedPreferences
✅ updateStarredPlanIds() - Saves plan IDs to SharedPreferences
✅ updateLastAckedJwtId() - Saves JWT ID to SharedPreferences
✅ Context passed to constructor and stored as appContext

Impact: ✅ Proper state management and pagination support enabled

3. Add Error Handling and Retry Logic

Status: ✅ COMPLETE

Current State: ✅ Implemented - fetchContentWithRetry() with exponential backoff

Location: TestNativeFetcher.java → fetchContentWithRetry()

Implementation Status:

✅ Retry logic for network failures (transient errors) - fetchContentWithRetry() with MAX_RETRIES = 3
✅ Distinguish retryable vs non-retryable errors - shouldRetry() method checks response codes and retry count
✅ Log error details for debugging - Detailed logging with retry counts and error messages
✅ Exponential backoff for retries - RETRY_DELAY_MS * (1 << retryCount) implemented

Suggested Implementation:

private static final int MAX_RETRIES = 3;
private static final int RETRY_DELAY_MS = 1000;

private CompletableFuture<List<NotificationContent>> fetchContentWithRetry(
    FetchContext context, int retryCount) {
    // ... existing fetch logic ...
    
    if (responseCode == 401 || responseCode == 403) {
        // Non-retryable - authentication issue
        Log.e(TAG, "Authentication failed - check credentials");
        return CompletableFuture.completedFuture(Collections.emptyList());
    }
    
    if (responseCode >= 500 && retryCount < MAX_RETRIES) {
        // Retryable - server error
        Log.w(TAG, "Server error " + responseCode + ", retrying... (" + retryCount + "/" + MAX_RETRIES + ")");
        Thread.sleep(RETRY_DELAY_MS * (1 << retryCount)); // Exponential backoff
        return fetchContentWithRetry(context, retryCount + 1);
    }
}

Impact: Improves reliability for transient network issues

🟡 Medium Priority

4. Validate API Response Structure (Need to Verify Actual Structure)

Status: ✅ VERIFIED - Endpoint structure verified, parser validation needs improvement

Current State: Parser handles both flat and nested structures, but could add more validation

Location: TestNativeFetcher.java → parseApiResponse()

✅ Endpoint Structure Verified:

✅ Check endorser-ch endpoint implementation:
- ✅ Found /api/v2/report/plansLastUpdatedBetween handler in endorser-ch source: ~/projects/timesafari/endorser-ch/src/api/controllers/report-router.js
- ✅ Verified actual response structure - Returns { data: [...], hitLimit: boolean } where data items have plan and wrappedClaimBefore properties
- ✅ Response matches PlanSummaryAndPreviousClaim structure - Items have plan.handleId, plan.jwtId, and wrappedClaimBefore properties
✅ Current parser handles:
- ✅ Both flat structure (jwtId, planId) and nested structure (plan.jwtId, plan.handleId)
- ⚠️ Missing: Does NOT extract wrappedClaimBefore from response (exists in API response but not used in parser)

✅ Verification Results:

Null Checks Status:

✅ Uses .has() checks before accessing fields (planId, jwtId) - Lines 502, 511
✅ Checks item.has("plan") before accessing plan object - Lines 504, 513
✅ Checks dataArray != null after getting it - Line 491
✅ Handles null values safely (planId and jwtId can be null) - Lines 499-518
✅ Wrapped in try-catch for error handling - Line 485, 570
⚠️ Missing: No check for root.has("data") before calling getAsJsonArray("data") (line 490) - Could throw IllegalStateException if "data" field missing or wrong type
⚠️ Potential Issue: getAsJsonObject("plan") (lines 505, 514) could throw if "plan" exists but is not a JsonObject (currently caught by try-catch)

Structure Validation Status:

⚠️ Missing: No validation that root has "data" field before accessing (line 490)
⚠️ Missing: No warning logged if "data" field is missing or wrong type (would be caught by try-catch, but no specific warning)
✅ Handles missing/null data gracefully (creates default notification if contents empty) - Line 554-568
✅ Handles parse errors gracefully (returns empty list on exception) - Line 570-573

Nested Structure Handling:

✅ Handle nested structures correctly - Parser handles both item.plan.handleId and item.planId formats
✅ Handles both flat (jwtId, planId) and nested (plan.jwtId, plan.handleId) structures

Remaining Work:

Add root.has("data") check before accessing data array (line 490 - currently could throw if "data" missing)
Add null check for plan object before accessing nested fields (line 505, 514 - currently relies on try-catch)
Log warnings for unexpected response formats (missing "data" field, wrong types)
Extract wrappedClaimBefore from response items (API provides this but parser doesn't use it)

Suggested Improvements:

private List<NotificationContent> parseApiResponse(String responseBody, FetchContext context) {
    try {
        JsonParser parser = new JsonParser();
        JsonObject root = parser.parse(responseBody).getAsJsonObject();
        
        // Validate response structure
        if (!root.has("data")) {
            Log.w(TAG, "API response missing 'data' field");
            return Collections.emptyList();
        }
        
        JsonArray dataArray = root.getAsJsonArray("data");
        if (dataArray == null) {
            Log.w(TAG, "API response 'data' field is not an array");
            return Collections.emptyList();
        }
        
        // ... rest of parsing with null checks ...
    }
}

Impact: Prevents crashes on unexpected API responses

5. Add Comprehensive Logging for Debugging

Status: Partial - Basic logging exists, more comprehensive logging needed

Current State: Basic logging present (Log.d/i/e/w), but could be more detailed and structured

Location: Throughout TestNativeFetcher.java

Current Implementation:

✅ Uses Log.d/i/e/w for different severity levels
✅ Some structured tags (e.g., "TestNativeFetcher")
✅ Logs error details and retry information

Required Changes:

Add more comprehensive log levels (DEBUG, INFO, WARN, ERROR) - Basic levels exist but could be more systematic
Log request/response details (truncated for sensitive data) - Some logging exists, could be more comprehensive
Log timing information for performance monitoring - Not currently implemented (timing would be helpful)
Add structured logging tags for filtering - Basic tags exist, could be more structured with consistent prefixes

Suggested Logging Points:

Configuration received
Fetch start/end with timing
HTTP request details (URL, method, headers - sanitized)
Response code and size
Parse success/failure
Number of notifications created

Example:

Log.d(TAG, String.format("FETCH_START trigger=%s scheduledTime=%d fetchTime=%d", 
    context.trigger, context.scheduledTime, context.fetchTime));
    
long startTime = System.currentTimeMillis();
// ... radius logic ...
long duration = System.currentTimeMillis() - startTime;

Log.i(TAG, String.format("FETCH_COMPLETE duration=%dms items=%d", 
    duration, contents.size()));

6. Implement Proper Context Management

Status: ✅ COMPLETE

Current State: ✅ Context passed to constructor and stored

Location: TestNativeFetcher.java constructor, TestApplication.java

Implementation Status:

✅ Pass Application context to TestNativeFetcher constructor - Done in TestApplication.onCreate()
✅ Store context for SharedPreferences access - Stored as appContext and used for SharedPreferences
✅ Using application context (no leaks) - context.getApplicationContext() used

Example:

// In TestNativeFetcher:
private final Context appContext;

public TestNativeFetcher(Context context) {
    this.appContext = context.getApplicationContext(); // Use app context
    // ... initialize SharedPreferences ...
}

// In TestApplication.onCreate():
Context context = getApplicationContext();
TestNativeFetcher fetcher = new TestNativeFetcher(context);

🟢 Low Priority / Nice to Have

7. Add Unit Tests

Status: Not started

Location: Create TestNativeFetcher/CONTENT_FETCHERTest.java

Coverage Needed:

JWT token generation (verify signature format)
API response parsing (valid and invalid responses)
Error handling (network failures, invalid responses)
Configuration updates
SharedPreferences integration

Test Framework: JUnit 4/5 + Mockito

8. Extract JWT Generation to Utility Class

Status: Not started

Current State: JWT generation code embedded in fetcher

Benefit: Reusable across other parts of the app, easier to test

Location: Create test-apps/daily-notification-test/android/app/src/main/java/com/timesafari/dailynotification/test/JwtUtils.java

9. Add Request/Response Interceptors for Development

Status: Not started

Purpose: Log full request/response for API debugging

Implementation:

Add methods to log full HTTP requests/responses (with data sanitization)

Note: Only enable in debug builds for security

10. Support API Response Caching

Status: Not started

Current State: Always fetches from API

Enhancement:

Cache successful responses with TTL
Use cached data if available and fresh

Use Case: Reduce API calls when multiple notifications scheduled close together

11. Add Metrics/Telemetry

Status: Not started

Purpose: Track fetch success rates, latency, error types

Implementation:

Record metrics to SharedPreferences or analytics service
Track: success/failure rate, average response time, error distribution
Log summary periodically

12. ✅ MOVED TO HIGH PRIORITY: Verify API Response Structure

This item has been moved to High Priority item #4 - Validate API Response Structure

Action Required (covered in item #4 above):

✅ Check endorser-ch source code for actual endpoint response structure
✅ Compare with PlansLastUpdatedResponse and PlanSummaryWithPreviousClaim interfaces in codebase
✅ Update parser if structure differs - Parser handles both flat and nested structures
Add validation for required fields - Additional validation still needed
Test with real API responses from endorser-ch server - Pending real API testing

Location:

Check endorser-ch source: src/ or server/ directories for endpoint handler
Check src/definitions.ts in this codebase for expected interface structure
Test with real responses from running endorser-ch server

📝 Configuration & Setup Tasks

13. Enable Real API Calls in Test Config

Status: Ready to enable - ES256K JWT generation complete, network config ready

Current State: TEST_USER_ZERO_CONFIG.api.serverMode = "mock"

Ready to Enable: ES256K JWT generation is complete, network security config is in place

Action:

Change serverMode to "localhost" in test-user-zero.ts (line 28) for emulator testing
Test API calls to http://10.0.2.2:3000 with real ES256K signed tokens
Verify tokens are accepted by endorser-ch API
Update to "staging" or "production" for real environment testing when ready

Location: test-apps/daily-notification-test/src/config/test-user-zero.ts (line 28)

Note: JWT generation now uses generateEndorserJWT() which creates proper ES256K signed tokens from the seed phrase.

14. Update TypeScript Type Definitions

Status: ✅ VERIFIED - Type definitions exist and are being used, may need updates after ES256K changes

Current State: Using as any type assertion for configureNativeFetcher in HomeView.vue

Verification Results:

✅ configureNativeFetcher() method added to plugin interface (src/definitions.ts) - Verified: Line 376
✅ Method signature exists with apiBaseUrl, activeDid, jwtSecret parameters
✅ Method is being called in HomeView.vue - Line 474 (onMounted hook)
✅ Currently uses (DailyNotification as any).configureNativeFetcher type assertion - Line 454

Remaining Work:

Rebuild plugin package to ensure TypeScript definitions are up to date in dist/
Remove as any type assertion in HomeView.vue (after confirming types are available)
⚠️ CRITICAL: Update method signature after ES256K implementation (remove jwtSecret, add private key mechanism)

Location: test-apps/daily-notification-test/src/views/HomeView.vue - Currently uses (DailyNotification as any).configureNativeFetcher

15. Add Network Security Configuration

Status: ✅ COMPLETE - Network security config created and AndroidManifest.xml updated

Purpose: Allow HTTP connections in Android emulator (for localhost:3000)

Verification Results:

✅ Checked: network_security_config.xml does NOT exist in android/app/src/main/res/xml/
✅ Checked: No networkSecurityConfig attribute in AndroidManifest.xml
✅ Checked: No usesCleartextTraffic attribute in AndroidManifest.xml

Implementation Status:

✅ Created android/app/src/main/res/xml/network_security_config.xml allowing cleartext traffic for 10.0.2.2, localhost, and 127.0.0.1
✅ Added android:networkSecurityConfig="@xml/network_security_config" to <application> tag in AndroidManifest.xml
✅ Documented that this is safe for development (emulator-only access)

Files Modified:

test-apps/daily-notification-test/android/app/src/main/res/xml/network_security_config.xml (created)
test-apps/daily-notification-test/android/app/src/main/AndroidManifest.xml (updated line 10)

Note: Required for HTTP connections (not HTTPS) to http://10.0.2.2:3000 from Android emulator

🧪 Testing Checklist

Before considering this implementation complete:

⚠️ CRITICAL: JWT tokens are accepted by endorser API (pending ES256K implementation - current HMAC-SHA256 will fail)
API responses are correctly parsed into notifications
Notifications appear at scheduled times
Prefetch occurs 5 minutes before notification
✅ Error handling works for network failures - Retry logic implemented
✅ SharedPreferences persists starred plan IDs - Implementation complete
Pagination works with afterId parameter (SharedPreferences ready, needs API testing)
Multiple notifications can be scheduled and fetched
Background fetches work when app is closed
✅ App recovers gracefully from API errors - Error handling and retry logic implemented

docs/NATIVE_FETCHER_CONFIGURATION.md - Native fetcher configuration guide
src/types/content-fetcher.ts - TypeScript type definitions
src/definitions.ts - PlansLastUpdatedResponse and PlanSummaryWithPreviousClaim interfaces
examples/native-fetcher-android.kt - Example Android implementation
Investigation Results: INVESTIGATION_JWT_ALGORITHM_RESULTS.md - ✅ Complete investigation findings
endorser-ch Repository - CONFIRMED: Uses did-jwt.verifyJWT() with DID resolver for ES256K verification
- JWT verification: ~/projects/timesafari/endorser-ch/src/api/services/vc/index.js - decodeAndVerifyJwt()
- /api/v2/report/plansLastUpdatedBetween endpoint handler: ~/projects/timesafari/endorser-ch/src/api/controllers/report-router.js
did-jwt Library - DID-based JWT implementation (JavaScript reference)
TimeSafari Repository: ~/projects/timesafari/crowd-funder-for-time-pwa/src/libs/crypto/vc/index.ts
- CONFIRMED: Uses createEndorserJwtForKey() with did-jwt.createJWT() and ES256K signing
- Signs with Ethereum private key from DID identity
- Reference implementation for production JWT generation

Notes

JWT Implementation: ✅ CONFIRMED - TimeSafari repository investigation complete. Endorser-ch API uses DID-based JWTs (ES256K) for API authentication. Current HMAC-SHA256 implementation must be replaced. See INVESTIGATION_JWT_ALGORITHM_RESULTS.md for complete findings.
Context Dependency: Consider whether TestNativeFetcher should be a singleton or if context should be injected differently
Error Strategy: Decide on error handling strategy - should fetches fail silently (current), or propagate errors for user notification?
State Management: Consider whether starred plan IDs should be managed by the app or fetched from API user profile
Investigation Status: ✅ Item #1 (JWT algorithm) investigation COMPLETE. Confirmed ES256K requirement. Implementation changes required before proceeding with other items.

✅ Verification Summary (2025-10-31)

Items Verified Through Code Inspection:

Item #4 (API Response Structure):
- ✅ Endpoint structure confirmed in endorser-ch source
- ✅ Parser handles both flat and nested structures
- ✅ Null checks exist for most fields (uses .has() checks)
- ⚠️ Missing: root.has("data") check before accessing data array
- ⚠️ Missing: wrappedClaimBefore extraction from response
Item #14 (TypeScript Types):
- ✅ Method exists in src/definitions.ts (Line 376)
- ✅ Method signature includes apiBaseUrl, activeDid, jwtSecret
- ✅ Method being called in HomeView.vue (Line 474, onMounted hook)
- ⚠️ Currently uses as any type assertion (needs plugin rebuild for proper types)
Item #15 (Network Security Config):
- ✅ Confirmed: network_security_config.xml does NOT exist
- ✅ Confirmed: No networkSecurityConfig attribute in AndroidManifest.xml
- ✅ Confirmed: No usesCleartextTraffic attribute in AndroidManifest.xml
- Needs to be created for HTTP connections to http://10.0.2.2:3000

Last Updated: 2025-10-31 (Checkboxes updated - Items 4, 14, 15 verified through code inspection)
Next Review: After ES256K JWT signing implementation is complete

32 KiB Raw Blame History

TODO: Test App Native Fetcher Improvements

📊 Progress Summary

✅ Completed High-Priority Items

✅ Critical Implementation Complete (Item #1)

🟡 Medium Priority Status

🟢 Low Priority

📝 Configuration Tasks

🔴 High Priority

1. ⚠️ JWT Generation and Verification Status

2. Implement SharedPreferences Persistence for Configuration

3. Add Error Handling and Retry Logic

🟡 Medium Priority

4. Validate API Response Structure (Need to Verify Actual Structure)

5. Add Comprehensive Logging for Debugging

6. Implement Proper Context Management

🟢 Low Priority / Nice to Have

7. Add Unit Tests

8. Extract JWT Generation to Utility Class

9. Add Request/Response Interceptors for Development

10. Support API Response Caching

11. Add Metrics/Telemetry

12. ✅ MOVED TO HIGH PRIORITY: Verify API Response Structure

📝 Configuration & Setup Tasks

13. Enable Real API Calls in Test Config

14. Update TypeScript Type Definitions

15. Add Network Security Configuration

🧪 Testing Checklist

📚 Related Documentation

Notes

✅ Verification Summary (2025-10-31)

32 KiB

Raw Blame History