suggestion: `{repo}/goodfirstissues` as shorthand URL for open issues with `good-first-issue` tag #496

brilliant idea though, for the implementation, you would just have the appview/repo/router.go have a new handler that just redirects to {repo}/issues?q=... with the right query param for the label filter.

More or less what I thought on poking around a bit. The one snag that sticks out to me about the naming is that it could then create (more) confusion in having contribute in one place and goodfirstissues elsewhere (itself referencing good-first-issues)

New question: are redirects (or, generally, getting the results of some hard-coded URL) something that Chi router can do out of the box, or do I need to write a custom handler for that?

(Looking at this codebase I'm also a little unsure just how such a thing would need to be scoped, but that's on a pretty shallow read of a language I don't really know.)

On second thought why not route both names (at both the sitewide and repo level) to one place (each)?

On the redirect piece, I'm going to need to do small to moderate research dives on how Go handles redirects and how to get this dev environment up and running (which I was less concerned about for small typos), but will come back to this.

do have a look at the hacking section on docs.tangled.org! should be super easy to get setup.

good idea. I'd like to keep /contribute for more crazy dashboard-like page. Would be super cool.

/goodfirstissues is bit too long and easy to miss imo. It's just redirection, so we can have many:

• /goodfirstissues
• /goodfirstissue
• /gfi all redirect to same issues page with gfi filter.

@boltless.me Do you have a preference for how this might look in externally-facing language? I have a related PR open for adding the site-wide page to the various footers, but wasn't sure what one (other) word would summarize that best

I think using "contribute" in blog navigating to gfi is completely fine. Maybe we can be more precise in appview footer? That would need a larger footer so I'm not sure.

cc @eti.tf

lgtm! don't think this requires an elaborate design, direct code impl sounds ok to me

@boltless.me if they're being used for different things it could get confusing later, but yeah

My other after-the-fact thought was to have this and the general Tangled repo link say "code (read)" and "code (write)," but that's maybe just that I like how it sounds/reads more than it is that it's necessarily better...

@oppi.li just coming back to this after a couple days out of town... also new to Nix (as a user), but if I'm understanding these docs and this overall flow correctly, Nix sets up the overall dev environment, which is separate from my actual OS install, and then I am essentially opening that in a container of some kind when I run nix develop? And all the deps have to be started manually from there?

Is there a docker-compose or equivalent anywhere within Nix that I could use to start them all together? (And if not, do you have any structural opinions about eventual PRs contributing one? Either way I will potentially have other, similar ones to flesh out docs accordingly.)

@eti.tf (or @boltless.me or anyone else in this thread who does know Golang) if I'm understanding this correctly after a small research dive, redirects are handled directly by std/http, right?

nix(language) != nix(package manager) != NixOS (operating system)

When you run nix develop, it just opens a new shell with configured binary available in PATH. We don't have docker-compose yet. Running nix run .#watch-appview under devshell (shell opened by nix develop) should be enough to test the appview.

And yes, you can just use standard http package. See appview/strings/strings.go:174 as an example.

nix(language) != nix(package manager) != NixOS (operating system)

Yes, this much I was aware of, but I was unsure where the boundaries were with the shell vs the rest when using Nix anywhere other than its own OS.

Got it, I'll try that and let you know if I run into any more snags.

Ok new problem -- after trying to run my changes first (bad idea), going down rabbit holes because I managed to miss/forget this link, and eventually trying to see if I could get it running unmodified, I got a separate error around Redis. How do I get this running via Nix? (Does it have to be via Nix? Nix the package manager is doing distinct package versioning at the project level here if I'm understanding it right, yes?)

Anyway here's my error output if it's helpful:

2026/05/09 15:05:29 ERRO appview: failed to create redis resolver err="could not connect to redis identity cache: dial tcp 127.0.0.1:6379: connect: connection refused"
2026/05/09 15:05:30 ERRO appview: failed to start appview err="failed to start oauth handler: failed to connect to redis: dial tcp 127.0.0.1:6379: connect: connection refused"

As stated from our doc, you just need to run redis-server in background, which is included in PATH if you are in tangled devshell nix develop.

Got it, must have missed that. Meanwhile I have something at least starting to compile now, so I'll attempt to get a PR in for this sometime over the weekend (assuming this is working in the way I think it is on testing it)

Got the dev environment compiled and running. Now, is it possible to view the upstream Tangled feeds using the local dev instance, or do I have to be running a knot locally to test things like timeline and repo views?

both can work! you can leave the appview for a while so it can ingest enough data to show. We don't have backfill yet.

Confusingly, it shows activity on the homepage (follows, mostly), but on most of them, when I try to click through to one of those same profiles I get "this user hasn't joined Tangled yet"

The handful of exceptions still aren't showing any repos

(The ingester itself is showing various error logging as I navigate, if that matters)

yes, that's expected behavior for current appview. As we don't support backfilling yet, only new events will show up. And some pages might seem broken due to missing records. In that specific case, mostly due to sh.tangled.actor.profile records haven't been ingested.

So it would basically mean leaving the appview open long enough to find someone creating a new user account and repo?

actually wait for a bit. I'm working on a more user friendly development environment.

Is this piece still TBD?

oh sorry. It isn't merged yet, but you can find it from https://tangled.org/tangled.org/core/pulls/1495/round/2

Yes.

I'm actively looking at how to do this myself as an excuse to get my hands on a bit of Golang, but wanted some feedback on the feature request first

good second issue i suppose!