Working Group Meeting: March 20, 2026

[julietshen]

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:

• Outstanding PRs
• Upstreaming anything useful (Hailey's ATproto work, Matrix K8s?)
• Adopter questions/topics
• Any additional contributor topics

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

[julietshen]

based on the conversation on Discord, maybe

• version upgrades

[julietshen]

Notes

• @vinaysrao1 to review Add FawltyDeps for unused deps, single source of truth for dependencies, and turn on CI #159
• biggest concerns on dependabot PRs is around what could break. for example, grpcio will not be upgraded. We could bundle all the small dependency updates in a PR and do some testing. Could convert into one issue and ask Community to verify ones that they're familiar with.
• Even if something doesn't break, there could be other tradeoffs like memory usage or something. Each PR should be for one corresponding dependency change.
• @haileyok could take on a few small ones and run outside production to check, might ask @cmttt for help too.
• A few dependabot bumps are listed in Add FawltyDeps for unused deps, single source of truth for dependencies, and turn on CI #159 as dependencies that were removed. Let's merge Add FawltyDeps for unused deps, single source of truth for dependencies, and turn on CI #159 first and that will close some of these out.
• refactor: migrate Dict and List to native types across codebase #106 has been ready for review for some time, and Migrate python collection types from typing types to native types #134 which touches many more files. Tests are failing on 134 but not on 106. We could try rebasing 134 on 106 which could pull Rashmi's work into 134. Can also add Rashmi as a co-commiter to attribute work to multiple people when merging the PR.

pulling Druid out

• looks like it might need to be done in 2 stages. Could remove Druid JSON model upstream and is more of a design decision and we can keep Druid but get that change made, and then we can make the storage interface plugginizable and make Druid/Clickhouse/etc. We can log as an issue for discussion or for someone to pick up the work. How could we do this without breaking Discord's implementation?
• TODO: create a new Discussion around this redesign

How to find Osprey-familiar developers?

• There are organizations who might want to adopt Osprey but don't have their own eng resources. This might be a big blocker for people who want to use Osprey who don't have an event stream application.
• It's hard right now to figure out who works on Osprey and might be open to contract work
• Osprey project needs clarification on what Osprey needs as a foundation, and what software needs it requires (like an event stream). Can documentation be improved to address this?
• We could document our way out of this, or supporting a webhook that people can use.
• TODO: add documentation on why different pieces of tech (ie. Kafka, Druid, etc) were chosen, as well as documentation on how someone with their own software can use ROOST projects
• more reference architecture!!
• These docs can look like: what do we mean by an "event stream", "here's how to get from crud architecture to an event stream", a good CLAUDE.md file, explaining/mentioning Change Data Capture or debezium. (anyone else on the wg call, please update this part of the notes pls)
• TLDR; we need more guides and docs on "how do i get my data into ROOST tools"

Kafka

• could also spin up an open source job board for developers familiar with ROOST tools
• want to understand the blockers and pain points for orgs using kafka for different things
• @haileyok @ThisIsMissEm help pls with notes <3

[julietshen]

• Could be a good write up on why T&S works well with events and why a stream of events is helpful for doing trust and safety

[ThisIsMissEm]

The general main pain point for kafka is that many applications are coming from the "here's my fairly traditional CRUD application, with maybe an worker queue for background jobs", and kafka for many users may be completely unnecessary (because they don't care about running tools like coop or osprey), and kafka generally has a history of being somewhat scary because it used to depend on zookeeper.

The other main pain point is getting people to understand why events are important for trust and safety in the first place, and then how do we get those events to be produced whilst retaining application level consistency.

[julietshen]

• Currently there is no Getting Started / Quick Start guide for Coop or Osprey. There are lots of features but new users may not know how to use it
• ie basic setup of how to input data, what the features do and what the end to end flow looks like.
• Coop docs are helpful in explaining how kafka works with the UI works with webhooks. Osprey doesn't have as much documentation that explains this. @haileyok had more documentation from her fork that got merged upstream
• The majority of the docs site for Osprey details contributing to the codebase, not actually using Osprey.
• @julietshen to create an issue logging this feedback and adding MUCH MORE DETAIL to the Osprey docs.
• Some details on Osprey auth would be nice.The path to having Osprey running without exposing it to the internet is unclear.
  • it is very not clear. discord uses okta and bluesky used oauth2 proxy. Neither of these options make sense really and while oauth proxy is helpful, making role-based access controls is very important (Oauth doesn't know the concept of RBAC).
• first docs: don't run Osprey on a publicly accessible port, run it via Tailscale or something to make it an internal service. This can become an exploit if it's run on a public port. Make this very clear in the documentation! @julietshen to create issue
• Could be a good ROOST blog on T&S tool primers along with assumptions around them (ie. always be an internal service, why event streams are helpful, etc).
• https://authzed.com/learn/google-zanzibar
  • https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/
• https://github.com/keycloak/keycloak

[ThisIsMissEm]

Rebasing / merging #134 and #106

• rebasing 106 to e794aa8 (the same point 134 branched off), you will encounter conflicts, which seem to be List vs list, I'm not sure which is correct.
• getting 106 up to the same starting point as 134 would probably be helpful for rebasing 106 into 134.