Suggestion: Prefix repo names with fgp- before the project grows

[twick00]

Suggestion: Prefix repo names with fgp- before the project grows

Hey! First off, really cool project. The daemon-based approach to replacing MCP stdio is a great idea and the benchmarks speak for themselves. Excited to see where this goes.

Since the project is still early, it might be worth renaming the GitHub repos to match the crates.io names (e.g. browser → fgp-browser, daemon → fgp-daemon, etc.). Right now names like daemon, browser, and github are super generic. On a Linux machine daemon especially just blends into the woodwork, and finding the right repo on GitHub is tough when the name could be anything. The crates.io packages already use the fgp- prefix, so aligning now while there are few stars/forks would be painless (GitHub auto-redirects old URLs).

Separately, I noticed that browser and github use path = "../daemon" in their Cargo.toml which breaks on a standalone clone, while travel/cli/fly/neon use git = URLs that work fine, and the fgp monorepo has 24 subdirs pointing at a ../daemon that doesn't exist in the repo. Standardizing on git = or crates.io version deps would make everything build independently.

Suggested changes:

• Rename all standalone repos to use the fgp- prefix (browser → fgp-browser, daemon → fgp-daemon, github → fgp-github, cli → fgp-cli, travel → fgp-travel, fly → fgp-fly, neon → fgp-neon, calendar → fgp-calendar, gmail → fgp-gmail, protocol → fgp-protocol, daemon-py → fgp-daemon-py)
• Switch browser and github Cargo.toml from path = "../daemon" to git = or crates.io version deps so they build without a sibling clone
• Fix the 24 subdirs in the fgp monorepo that reference path = "../daemon" with no daemon/ dir present; either add a workspace Cargo.toml or switch to registry deps

Happy to put together a PR for both the renames and the Cargo.toml migration if you're open to it, just let me know!

[twick00]

fast-gateway-protocol/browser#2
fast-gateway-protocol/github#1

[wolfiesch]

Hey, thanks for this — and for the two PRs on browser! Just merged both. The data-fgp-ref injection fix was a real catch, that was genuinely broken.

On the path = "../daemon" deps: Totally agree, this needs cleaning up. Your browser fix is in and I'll work through the rest of the repos when I get a chance.

On the fgp- repo renames: I hear you on the generic names — daemon especially is rough on a Linux box. I'm a bit torn though since within the fast-gateway-protocol org they're already scoped, so fgp-browser feels a little redundant. Going to hold off for now but good call flagging it early.

Appreciate the thoughtful writeup and the PRs!

[twick00]

Totally fair on the naming. Your call at the end of the day, and I'm not trying to push you in any direction.

The only reason I bring it up is that I think this project has some real potential, and I'd love to see it get the recognition it deserves. The question that stuck with me was just: will people gravitate toward fgp as a single monolithic thing (via fast-gateway-protocol/fgp), or will they want to pick and choose individual modules? For what it's worth, I'm going to be primarily using and contributing to fast-gateway-protocol/browser, and you're actually in a better position than most OSS packages here. You get to establish both the repo name and define an acronym, with both becoming synonymous with the project over time.

A few projects that lean into this well:

• https://github.com/brave/brave-browser
• https://github.com/brave/brave-core
• https://github.com/grafana/grafana-operator
• https://github.com/supabase/supabase-js
• https://github.com/tailwindlabs/tailwindcss-typography

The org scopes the project, the prefix builds the brand. But again, just food for thought. Excited to keep contributing either way. 👍🏻