Working Group Meeting: Jan 9, 2026

[cassidyjames]

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

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

Discussion topics:

1. What UDFs to include in upstream Osprey
2. Maintainership and code review expectations
3. Good first issues
4. Adopter questions/topics
5. Any additional contributor topics

We hope to see you there!

[haileyok]

A few examples of things that I've put together for UDFs that may be interesting to upstream at least in some capacity:

• censorize.py: https://github.com/haileyok/osprey-for-atproto/blob/atproto/example_plugins/src/udfs/censorize.py#L1640-L1920
  • Note that there is a somewhat similar functional to CleanString in https://github.com/roostorg/osprey/blob/main/osprey_worker/src/osprey/engine/stdlib/udfs/string.py#L129. That UDF also has some functionality for dealing with Unicode lookalikes, though the list of lookalikes is a good bit smaller. I also struggled to really get it to do what I wanted, particularly when dealing with lists.
• list.py: https://github.com/haileyok/osprey-for-atproto/blob/atproto/example_plugins/src/udfs/list.py
  • Basically, this lets you create a list directory in your ruleset with YAML-based lists for strings. See i.e. https://github.com/haileyok/atproto-ruleset/tree/main/lists
• cache.py: https://github.com/haileyok/osprey-for-atproto/blob/atproto/example_plugins/src/udfs/cache.py
  • Poorly named at the moment truthfully, but a small Redis-backed cache for things like window-based counters. Useful for a lot of different rule usecases.

[haileyok]

something else I remembered, adding in some example (...i'll try to think of a good one) of making an external api request in a rule would be nice, i.e. https://github.com/haileyok/osprey-for-atproto/blob/atproto/example_plugins/src/udfs/sentiment.py

it's not very complicated on the udf side of things, but some considerations that are non-obvious:

1. to use or not to use execute_async = True in the udf
2. adjusting OSPREY_RULES_SINK_NUM_WORKERS depending on throughput, number of events that actually trigger a network request, request duration, etc. the default value of 1 definitely is a no-go!
3. the likely desire to include a when_all argument in your UDF, since you might not always want to get a result!

on the when_all note, i think documenting how the execution flow works is pretty important. it's not initially obvious what happens here:

SomeRule = Rule(
  when_all=[
    1 == 0,
    SomeUDF(),
  ],
)

On one hand, it seems like it might have been nice for evaluation of things inside the when_all to execute one by one, i.e. if 1 == 0 is false then do not execute SomeUDF(). however, that's not how evaluation works and you'll end up with SomeUDF() getting evaluated no matter what. adding a when_all parameter can help there if you want to only execute in some circumstances.

can discuss that more, but should get documented and probably someone who has the most understanding of rule execution should advise on that

[cassidyjames]

Meeting Notes

UDFs

A lot of @haileyok's fork work is AT-specific, but the proposed UDFs are useful at least as starting points!

• Censorize and Cache are things Discord has internal equivalents for, but they may rely on other services so it can complicate making them generic.

• Lookalike characters (in Censorize): we've all lived this! If we get 80–90% of the way there it's super useful. Matrix folks appreciated it being proposed. <3

• Aside: if we wanted to go more complicated/full-featured for cache/counter down the line, we could build that but as it gets more complex it could harm adoption because it's another consideration: "should you use this, if you do you have to spin up these dependencies…". It doesn't burden the runtime at all if it's not used by adopters (it just doesn't run if unused).

  • We've heard from other potential adopters: "too many services to spin up", a recurring design question.

Next steps: open PRs, can discuss specifics in the PR comments. Don't need to define super strict inclusion rules at this point.

Maintainership & Code Review

Right now we have a bunch of names on equal footing in the CODEOWNERS; it would be nice to better define who is the maintainer(s) to more directly take on some of the ownership.

• From Discord, it could probably be @EXBreder or @cmttt
• Maintainership is more tactical (vs. strategic; big decisions would be more document-driven: write a proposal, get it out there, a couple of folks take ownership over that project/filing issues)
• Hailey doesn't mind doing reviews, but also has open PRs for UI stuff she'd like to get merged in. Maybe intdev folks? Ideally part of a maintainer's role to ensure reviews are happening.

Good First Issues

Kind of hard because a lot of us don't know enough about the codebase yet; will sort of bubble up as we get more adopters.

First step: file the issues we hit! Sometimes small bugs/issues are easy enough to tackle in the moment, but small feature requests (UDFs!) are a good place for starter issues.

Adopters

Matrix: got Osprey injesting from Synapse (was easy with the docker compose running locally). Question about BigTable: used for two things, audit log (commented out), and dumping Osprey Execution Results into cold storage but MinIO also seems to be doing that. Tasked w/getting Osprey K8-ized.

• Can turn off execution results storage, but will lose visualization in the UI; if you only care about the rules engine/timeseries data but not the raw event data you can just use Druid.

• BigTable OR MinIO; they're alternatives.

• @haileyok to cross-check k8s manifest with Shay

Other

Quick note for next time (maybe more of a Discord questions): as we think about new UDFs, you shouldn't always have to fork Osprey—what's the longer-term plan for "pluginizing" especially for UDFs?

[julietshen]

Thanks for the notes! Tagging in the intdev folks for visibility, especially around the UI PRs: @BinaryFiddler @caidanw @elijaharita