August 21, 2026

[cassidyjames]

Our bi-weekly working group call is 1730–1830 UTC!

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

Proposed discussion topics:

• PRs to review
• Shadowing Osprey use at Discord
• Release/milestone planning
  • Release cadence, especially with respect to downstreams/adopters
  • Next milestone?
  • Project board: is it useful? How can we use it more effectively?
• Adopter questions/topics
• Outstanding issue/PR triage
• Any additional contributor topics

[julietshen]

Detailed Notes

• Meeting timing: does this time slot work well for everyone?
  • Asking Discord folks in #osprey; generally works, but in a hack week this week
• PRs to review
  • POC clickhouse implementation #214: out of date; close for now
  • make kafka topic creation and partition config configurable via env vars #255: also out of date… chimosky to take a look
  • Bump protobuf 4.25.8 → 7.35.1 and regenerate gRPC bindings #349: let’s have @roostorg/Discord take a look
  • feat(publisher): degrade PubSubPublisher to noop when GCP credentials are absent #388: out of date; Juliet to pick back up
  • Add in-app rule authoring backed by a draft rules table #402: Emelia has a branch of this to break it into modules and make it more maintainable; will follow up; Add rule authoring/editing UI backed by the rule-drafts API #403 should be able to be rebased on top after
  • Bump grpcio to 1.82.1 #415: needs to be rebased and reviewed
  • feat(atproto): resolve DID to handle and display name via enrichment UDFs #418: Juliet to revisit
    • Is the UDF loaded by default? Should be loaded on demand so it’s not used if you’re not using the atproto plugin. (edit main.sml?)
    • ci(deps): make fawltydeps audit member pyprojects + enable undeclared check #420: approved, needs conflicts resolved
  • Fix CREATE TYPE race that can crash the worker on first boot #436: Emelia wonders if SQLalchemy has a locking mechanism to prevent two processes running the migrations at once
  • Add pluggable LLM API provider hook with tool calling #337: draft, but would like to get this worked on!
• Shadowing Osprey use at Discord
  • Juliet and Selena are interested in joining!
  • Other teams to shadow? Skywatch, Bluesky?
  • Need to check in on orgs that have told us they’re using Osprey; need to check in w/them first from ROOST, then can see if we can shadow
• Release/milestone planning
  • Upgrades could be breaking changes; new features (rule authoring) would make sense to cut a new release for
  • Release cadence, especially with respect to downstreams/adopters
    • Documenting this would be beneficial; e.g. 6-month cycle
  • Next milestone?
    • Rule authoring in UI
    • LLM-powered queries and rule recommendations
    • Juliet is planning to update public roadmap; needs more scoping
      • I.e. We’ve received feedback asking for batch processing
      • What UDFs would be helpful to include ootb?
        • HMA/hash matching/image similarity?
      • How to do enrichment in general? I.e. should it be done in UDFs, or before trying to execute rules?
        • For hash & match, an enricher would download the media from storage, then calculate the hash and decorate the event with that hash
        • For a link aggregator, an enricher might fetch the opengraph data for the URL and decorate the event with that data.
        • Essentially enrichment is adding data to events that you don't already have.
  • Project board: is it useful? How can we use it more effectively?
    • No current release milestone
• Adopter questions/topics
• Outstanding issue/PR triage
• Any additional contributor topics
  • would love feedback from Osprey contributors and adopters on ROOST’s proposal on how we plan to natively support open weights → https://github.com/orgs/roostorg/discussions/82
  • Plugins: could publish Osprey as a python package, then have a plugin API for registering other packages as plugins
  • Agentic contributions: we currently have agents documentation and an AI-assisted coding policy that says “the final product must be the contributor’s original work,” but it doesn’t explicitly cover cases where the contribution is submitted by an agent directly, e.g. with its own account, which we suspect may happen to ROOST projects. We should update this policy to clarify, and maybe consolidate the two docs/policies into the same place.
  • Document how/why Osprey requires a non-empty config alongside rules. Config entries are used for action sampling, for example
    • [docs] Explain SML ruleset configuration #462
    • Could also have a scaffolding command that creates required directories, noop rule, required configuration, etc.
  • Document deployment guide
  • Downstream packaging? E.g. for distros?
    • We maintain docker images upstream; npm or python packages when it makes sense, but right now no demand for distro packages. It’s open source
  • Do we have a ROOST-wide office hours/working group? There are some project-spanning topics like open weight LLM integration, data abstraction, etc. that are cross-project.
    • Not at the moment, but Cassidy has been thinking about it…
  • Create issue tracking auth/role-based access control in Osprey, allow for more discussion on approach / technical design
    • Does it make sense to duplicate this between Coop and Osprey, or should we have some shared component to manage accounts/permissions?
  • Future tools in the ROOST ecosystem?
    • Would it make sense to have a shared “actioner” project e.g. that handles a standard API from both Coop and Osprey, then you define the database queries or requests it has to make