Private vs Public Repos - Learning about GitHub

Keep tabs with the earlier pieces in this series: How I use AI to build things on HIVE and I created an opinionated Price Feed Widget and Got Blocked by Google.

If you have been following along, we have been reviewing exactly the "how" - including tips, tricks and detours - of working with "AI" to build things. Its a non-linear path, but we do have the tools, and its not usually all that hard (although it might be outside our comfort zone).

A nice update first - our work from the last post worked! The site is not marked as dangerous social engineering anymore :)

So let's get back to our series - while writing this I stumbled upon a new proposal with an old conversation about open source, sharing code and "where does the value live?".

Topical - because today we are going to talk about Public and Private repos! And make sure to keep an eye on the HIVE Thrive Playlist because @meno, @buttcoins and I recently had a great show talking about this topic, and it's next on my upload list - and it even had @acidyo popping on to chat with us as well and discuss his efforts and intentions around the AI sponsorships.

But let's get down to our lesson today:

Why almost anything starts private

The honest case for a private repo: unfinished opinions, business logic, embarrassing commit history, not wanting to defend half-baked decisions in public "yet" - these are real decisions that have big consequences especially depending on the project.

Let's tie this back directly to the "opinionated" price feed widget from the previous post — privacy as the space where an opinion gets to be wrong before it's public.

My goal in making the widget in the first place was "two-fold" - which in open source just means: I want it to serve my need FIRST - and if it serves anyone else's needs then that is even better. Now that its serving my needs just fine - we can double back and ask Claude about the steps of making such a private repo public - and the first step is to "check".

Always Check First - Public is PUBLIC

You agent knows (more or less) what to check - and I was able to follow along. But just out of curiousity, after we were done, I asked - "Hey, what are the steps to ensure that this repository is actually ready to be public?"

And you know what Claude said? "Great question Eco."

Let's check back with Claude and ask - What did we just do and why?

What we checked, and why - by Claude

1. Git history for secrets

We ran git log --all -p | grep -iE "api[_-]?key|secret|password|..." across every commit, not just the current files. This matters because a public GitHub repo exposes its entire history, forever — if a credential was ever committed and later deleted, it's still sitting in an old commit anyone can git log into. We found nothing, and the repo only had one commit to begin with, which made this an easy pass.

2. .gitignore coverage

We confirmed config.yaml, .env, and *.db were already excluded. The distinction: config.example.yaml (committed, generic, safe) vs. config.yaml (your real node URLs, real tokens, never committed). This is the difference between a template and your actual deployment.

3. Does the code do what the docs claim?

This was the biggest finding — the README and pyproject.toml advertised PostgreSQL and MongoDB storage backends that were never actually written. Anyone who tried database_url: "postgresql://..." would've hit a crash, not the graceful error the code implied. For a private repo only you use, that's a TODO. For a public repo, that's a trust problem on day one — especially awkward for a project whose whole pitch (the "opinionated" section) is "we tell you exactly what we're doing." We removed the false claims rather than rush the implementations.

4. Security hygiene of anything a browser loads

The Chart.js