I'm a developer out in the San Juans. For a few years I've been building li-nk: a tool for planning activities and finding people to do them with. It's built for the folks who organize things: you bring the group and activity, it handles planning, RSVPs, and discovery.

Everything's user-created. We don't curate or run events ourselves. It's not a discussion board.

It spans way more than one scene: arts & music, food & drink, tech, games,learning & languages, community, sports & fitness, family, wellness — and yes, plenty of outdoors. A few live examples of events and activity planning:

• https://li-nk.social/e/hike-around-sunrise-rock (Sunrise Rock hike)

• https://li-nk.social/e/kayak-touring-off-orcas (kayak off Orcas)

• https://li-nk.social/g/toorcamp (Toorcamp group)

A demo is available with no registration required: http://demo.li-nk.social . Or you may register at http://li-nk.social

Android/iOS apps in testing, public release(s) hopefully this week.

Not monetized yet, and whatever the model (donations + premium, or contextual ads/sponsorships), the floor won't move: we never sell profiles of you, we won't sell your data.

Built in the Salish Sea region. I'd love it useful locally first, though it works across the US.

Honest feedback welcome: what's missing, what would make you actually use it?

Proposal: a working group for operator-side Scala security (with a concrete first project)

A discussion starter — I'd like to gather a few people, not hand down a finished plan. Counter-ideas and other directions welcome.

Why I'm posting

I run a production platform built on Scala, and I want to be more deliberate about security — and to find others doing the same. The reporting side is well covered (security@scala-lang.org, plus the admin-only Security Announcements category), and there's clearly current momentum on the language itself: the team recently completed its first external security audit (funded by OSTIF, conducted by Quarkslab) focused on the Scala 3 compiler and standard library.

What I can't find is a space for the application/operator side — the people running Scala in production who want to track CVEs across their dependencies and the JVM runtime, share secure-ops practices, and compare notes. There's no security channel, no operator-facing guidance beyond a couple of docs, and no group organizing any of it.

What I'd like to start

A small, low-ceremony working group / community around operator-side Scala security. Concretely, that might be any of:

• a #security channel on the Discord and/or a forum tag people can follow,
• an occasional informal call or written check-in,
• a place to ask "is this dependency CVE something to worry about?" and get a useful answer.

I don't have a fixed shape in mind — I'd rather let the people who show up decide. The point is simply that operators running Scala in production have somewhere to find each other.

A concrete first project, so it doesn't just go quiet

Open-ended groups tend to fizzle, so I'd anchor this with one tangible deliverable: a community-maintained guide to tracking CVEs in a Scala/sbt project using the JVM tooling that already exists. Roughly:

• generating a CycloneDX SBOM from an sbt build and feeding it into continuous monitoring (OWASP Dependency-Track, or lighter on-ramps like Dependabot and OSV-Scanner),
• the Scala-specific wrinkles — binary-version suffixes on artifact coordinates (_3, _2.13) and how they interact with coordinate matching; keeping dependencies current with Scala Steward; secure-use notes for common libraries and effect systems,
• how the JDK itself is tracked separately (vendor advisories, Oracle Critical Patch Updates, the CISA KEV catalog).

I'm happy to write the first draft. It also gives the group an immediate, shared purpose rather than a vague "let's talk about security."

Why this scope (and why it's tractable)

The good news is we're not reinventing anything. Because Scala compiles to the JVM and publishes to Maven Central as ordinary Maven artifacts, our dependencies are already first-class citizens in the mature JVM/Maven security tooling — the work is mostly writing down how a Scala shop wires into it, plus the handful of Scala-specific gotchas.

Tellingly, the recent audit drew the same line: it scoped in the Scala 3 compiler and standard library, and scoped out third-party dependencies and JVM-runtime security. Those out-of-scope areas — our dependencies and the runtime they sit on — are exactly the operator territory this group would cover. (This isn't a new wish, either — a "secure coding standards for Scala" thread goes back to at least 2014 — but I couldn't find a living effort that came of it.)

Non-goals

• Not duplicating or competing with the Scala Security Team's vulnerability reporting — this is operator collaboration, not triage.
• Not building Scala-specific CVE infrastructure; the JVM ecosystem already covers our artifacts.
• Not runtime intrusion detection (Falco, WAFs, SIEM, and so on) — valuable, but largely language-agnostic and well covered elsewhere.

What I'm looking for — and I'd welcome other directions

• Is there already an effort like this that I've missed and should join instead?
• What would be most useful to you — a channel, a guide, periodic calls, a working group, something else?
• For those of you running Scala in production: what has actually bitten you, and what do you wish existed?

If even two or three people want to help shape or seed this, that's plenty to start.

A note to the Scala Center team

If you're reading this: I'd value knowing whether there's already an effort here I should join rather than start, and whether you'd be open in principle to operator-focused security guidance eventually living somewhere official — a page on docs.scala-lang.org, say. I'm glad to draft a first version; mostly I want to avoid duplicating existing work or reinventing infrastructure the JVM ecosystem already provides.

Appendix: the June 2026 Scala 3 audit, for operators

Scala's first external security audit — funded by OSTIF, conducted by Quarkslab, published June 2026 — reviewed the Scala 3 compiler and pipeline, generated bytecode, the REPL, the TASTy Inspector, Scaladoc, and parts of the standard library (collections, concurrency primitives, utilities). It reported 9 findings: 5 medium, 2 low, and 2 informational, with no high or critical issues, and most needing specific preconditions to exploit.

The ones worth an operator's attention:

• A deserialization gadget in the standard library (within scala.sys.Process) — reinforcing why ruling out untrusted deserialization matters (see the existing deserialization-security guide).
• A command-injection issue in the project's own GitHub Actions CI scripts — a reminder that build-pipeline hardening belongs on any secure-ops checklist.
• Standard-library robustness edge cases: an unexpected indexOfSlice result on an empty sequence, and an uncaught exception when tokenizing process arguments with unmatched quotes.

The remaining findings are compiler/tooling-internal (for example, a loop in the TASTy unpickler and a non-cryptographic RNG in the compiler) and aren't things an application owner needs to act on.

Most relevant to this proposal: the audit explicitly scoped out third-party dependencies and JVM-runtime security — the operator-side territory this group would cover.

Sources: Quarkslab report · OSTIF summary

Hi r/WWU

A few years ago, living on Orcas Island, I recognized something about small communities: I could be on the island and share the same interests as other people, and still not meet them for years. Sometimes longer. The people were around. We just didn't cross paths around the things we cared about.

That was part of the motivation for building li-nk. The other social platforms aren't really designed for this. They're built around who you already know, or around broadcasting to strangers. Neither one does much for the quieter work of finding the handful of people nearby who share what you care about.

And while the problem is sharpest in small places, it shows up everywhere, including in college towns where the campus is dense with people doing interesting things. You might spend a whole quarter without finding connection.

I've spent the last several years building li-nk to address this directly. The idea is simple: register the interests you actually care about, then create and find activities surrounding those interests. A Tuesday morning hike, finding study partners, a board game night, a mountain biking group ride, a pun and poetry slam.

The platform is organized around developing interests, and the activities that grow out of them. I'd really appreciate any feedback from the WWU community. Thanks for your consideration.l

Demo (no signup): http://demo.li-nk.social

Live: http://li-nk.social