Working Group Meeting: Feb 20, 2026

[cassidyjames]

We're having our bi-weekly virtual working group call this Friday at 1830–1930 UTC!

• Google Meet
• #osprey in the ROOST Discord
• Discord event series

Proposed discussion topics:

1. Outstanding PRs
2. Upstreaming anything useful (Hailey's ATproto work, Matrix K8s?)
3. Adopter questions/topics
4. Any additional contributor topics

Please feel to comment below with any additional agenda items or discussion topics! See you there!

[cassidyjames]

Notes

PRs

• Migrate python collection types from typing types to native types #134: @EXBreder to review <3
• refactor: migrate Dict and List to native types across codebase #106: similar to Migrate python collection types from typing types to native types #134 but smaller/older; review first
• configurable execution result store #29: makes minIO optional (can plug in something else); should be reviewable (used in some form at Bluesky to swap minIO to BigTable); @EXBreder to take a look
• add check censored udf, tokenize udf #121 @haileyok is not pressed to get this merged, would like to work on it some more

Upstreaming

Giulia was working on some UDFs; some are generic, but others may be ATproto-specific. How do we handle community UDFs especially when they're integration/protocol-specific?

• Ideal long-term: UDFs can live in their own repos
  • Can be done! But we should show it/document it. Maybe with Giulia's ATproto-specific UDFs

Upstreaming from Matrix: a guide for running Osprey in k8s would have been useful, could be contributed upstream!

• Matrix had to set up the deps from scratch, whereas Discord and Bluesky had Kafka, etc. already

Codeowners

Can/should we separate the idea of PR approvals (codeowners) from maintainers. 👍🏻 from the maintainers here.

Adopters

Matrix: still getting things up and running; nothing top of mind atm but we'll check back in in a couple of weeks

• Scaling: @haileyok has some experience and thoughts here that could be helpful for Matrix.

• Performance: similar story here; defaults in the Osprey repo are barebones and can cause problems

• Metrics: it'd be nice for Osprey to have Loki and Prometheus built-in somehow; debugging/monitoring is a pain rn

  • Note: mentally separate concerns of "performance metrics" from "usage/user metrics"

For smaller adopters:

• Osprey is big/complex, can/should it be simplified or would that be a smaller separate codebase?

  • Simpler docker compose to get things running for more barebones use case
  • Would you disable Osprey's UI completely, or does it still serve non-investigatory uses?

• Getting rid of Druid (everyone kind of wants to!): could be swapped with Postgres or timescaleDB… depends on throughput

  • Would need to write AST from SML to whatever db is swapped in (Druid's query language is… JSON[!]; would need to translate to SQL—but some features are db/SQL-implementation-specific)
    • SML → SQL for Clickhouse translator, Clickhouse implementation
    • New embedded SQL in Rust (apparently really fast!)