Peregrine Team Meeting - April 19, 2025

Phenom Internal Development Team Meeting (Project Peregrine)

Date: April 19, 2025 Time: 17:00 Vienna Time Location: https://meet.google.com/ojx-muwm-hsa Attendees: Peregrine Development Team, [List other attendees, e.g., Logan]

🎯 Meeting Objectives

1. Review the status and implications of the ABCloudz (Project Buzzard) source code handoff.
2. Discuss and align on the optimal backend storage solution for user-uploaded media (images/videos) for the Peregrine platform.
3. Define a preliminary strategy for annotating user-submitted media data, including C2PA standards.
4. Evaluate and make a preliminary decision on using Relational DB, Graph DB, or a hybrid approach for storing metadata and relationships.
5. Assign action items for research and next steps.

📝 Agenda

1. Welcome & Opening (5 mins)

   • Quick check-in.
   • Review meeting objectives.

2. ABCloudz Code Handoff Review ("Project Buzzard" Codebase) (15-20 mins)

   • Confirmation: Code successfully received and located in the designated GitHub repositories (Buzzard-iOS and Buzzard-Android).
   • Initial Assessment Plan:
     • Assign team members for initial code review (quality, structure, dependencies).
     • Goal: Understand the existing architecture (Firebase usage, Swift/Kotlin implementation details, 3rd party libs).
   • Strategic Discussion:
     • How much effort is needed for basic maintenance vs. full migration focus?
     • What can we leverage/learn from this codebase for Peregrine?
     • Identify immediate risks or dependencies (e.g., specific Firebase setup).
   • Goal: Define immediate next steps for handling/understanding the Buzzard codebase.

3. Backend Storage for User Media (Images/Videos - Peregrine) (25-30 mins)

   • Requirement Review: Scalability, cost-effectiveness, durability, security, accessibility (API integration), performance (upload/retrieval), potential for future analysis hooks.
   • Option Evaluation:
     • AWS S3 (Simple Storage Service)
     • Google Cloud Storage (GCS)
     • Azure Blob Storage
     • Other relevant options?
   • Discussion Points:
     • Pros/Cons of each based on requirements.
     • Estimated cost comparison (storage tiers, egress fees, request pricing).
     • Ease of integration with our planned Peregrine tech stack (React Native, Expo).
     • Data residency considerations (if any).
   • 💡 My Insight:
     • Dedicated object storage (S3, GCS, Azure Blob) is the industry standard and almost always superior for storing large binary files like images and videos compared to storing them directly within a database (relational or graph). Databases should store metadata and a reference (e.g., the object storage URL/key) to the file.
   • Goal: Narrow down options to 1-2 preferred solutions for deeper investigation or make a preliminary decision.

4. Media Data Annotation Strategy (15-20 mins)

   • Identify Key Annotation Data Points:
     • Auto-Captured: Geolocation (if possible/accurate), Timestamp, Device Info (OS, Model), EXIF data from images, Sensor Data.
     • User-Provided: Tags/Keywords, Description/Witness Account, Phenomenon Type (UAP, Cryptid, Paranormal - predefined list?), Confidence Level?
     • System/AI-Generated: Potential image/video analysis tags (object detection, environmental conditions?), Quality Score?
     • Internal Team: Verification status, Case ID links?
   • Annotation Mechanisms:
     • During upload process (required fields?).
     • Post-upload editing interface.
     • Automated extraction tools/services.
   • Data Structure Considerations: How will these annotations be structured for storage and querying? (Leads into next topic).
   • Goal: Define an initial list of desired annotations and potential methods for capturing them.

5. Database Strategy for Metadata & Relationships (Peregrine) (25-30 mins)

   • Recap: We need to store user data, media metadata (linking to object storage), annotations, and the relationships between sightings, users, locations, tags, etc.
   • Option Evaluation:
     • Relational DB (e.g., PostgreSQL, MySQL, continue with Firestore?)
       • Pros: Structured data, ACID compliance, mature ecosystem, familiar SQL.
       • Cons: Can become complex to model and query highly interconnected, evolving relationships (e.g., linking multiple sightings to the same location/witness over time).
     • Graph DB (e.g., Neo4j, AWS Neptune, ArangoDB)
       • Pros: Excels at managing and querying complex relationships. Flexible schema. Intuitively models networks of interconnected data points (sightings -> location -> witness -> tags).
       • Cons: Different query languages (Cypher, Gremlin), potentially different scaling considerations, newer tech for some team members.
     • Hybrid Approach
       • Pros: Use each DB type for its strengths. Relational for core user/file metadata; Graph for the complex web of sighting relationships, annotations, locations, etc.
       • Cons: Increased infrastructure complexity, potential data consistency challenges between DBs, need for expertise in both.
   • 💡 My Insight:
     • The core value proposition of Phenom involves understanding connections between phenomena. This inherently suggests graph-like relationships (sightings near location X, sightings by user Y, phenomena with similar tag Z). While starting purely relational (like Firestore) is possible, anticipating the need for graph capabilities is wise. A hybrid approach is often powerful but adds complexity. Consider if Firestore’s structure is sufficient or if a dedicated Graph DB (even alongside Firestore/Relational) is warranted for relationship analysis.
   • Goal: Discuss trade-offs and make a preliminary decision on the database direction (Relational, Graph, Hybrid) to guide further technical design.

6. Improving App Store Presence & Statistics (20-25 mins)

   • Review Current Stats: Briefly discuss current ratings, reviews, crash rates, performance metrics (App Store Connect, Google Play Console).
   • Brainstorm Strategies:
     • Non-Code: Marketing initiatives, community engagement, in-app prompts for reviews (timing/frequency), improving support channels, App Store Optimization (ASO - keywords, description, screenshots).
     • Code: Addressing top crashes, improving performance (startup time, responsiveness), UI/UX refinements based on feedback, implementing analytics for better insights.
   • Issue Creation Plan: Discuss how to capture actionable items (code changes, research tasks, marketing tasks) as issues (e.g., in GitHub Issues, Linear).
   • Goal: Identify key areas for improvement and outline a plan for creating actionable issues covering both code and non-code strategies.

7. Action Items & Next Steps (10 mins)

   • Summarize key decisions/directions.
   • Assign specific owners and deadlines for:
     • Buzzard code review tasks.
     • Deeper research into top 1-2 storage solutions (cost modeling, PoC?).
     • Refining the annotation list.
     • Deeper research into chosen DB strategy (PoC, schema design?).
     • App Store improvement tasks (code & non-code issues).
   • Schedule follow-up meeting if needed.

8. Q&A / Wrap-up (5 mins)