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 
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 tag was pulling an unpinned, floating version (@4) with no integrity check — meaning a compromised CDN could silently swap in malicious JS for every embedded chart. We pinned an exact version with a Subresource Integrity (SRI) hash. This one connects directly to article 2: an unpinned CDN script with no CSP/SRI was literally one of the findings (F6) in the Safe Browsing remediation for the sibling ecobank site. Public code gets scrutinized (and scraped, and scanned) in a way private code doesn't.
5. Abuse resilience
Added a simple 30-second cache on the read endpoints so a burst of traffic (real users, bots, or someone's monitoring script hitting /chart every second) doesn't hammer the Hive-Engine node or CoinGecko on your behalf. Not critical at zero users, but "what happens under load I don't control" is a different question once the repo is public and clonable by anyone.
6. Legal clarity
No LICENSE file existed. Under default copyright law, that legally means "all rights reserved" — nobody can legally fork, modify, or reuse the code even though the repo is visible. We added MIT, matching the "open data" spirit you wanted publicly.
7. Contribution norms
Added CONTRIBUTING.md codifying what you already said in article 2 informally ("tightly-scoped PRs, comments welcome, we review real effort") — so it's stated once, in the repo, instead of scattered across blog posts people may not have read.
8. Comparing against the downstream fork
We diffed this repo against ecobank/app/utils/token_price.py — the copy that actually runs in production — to make sure the "origin" repo wasn't secretly missing a bugfix that only landed in the fork. It wasn't; the fork was a simplified subset, not an improved one. This check exists because it would be embarrassing to publish the "canonical" version of something and have it be worse than the copy already running live.
9. README as the actual product
For a public repo, the README is the pitch — most people decide whether to trust or use something from it alone, without reading code. We fixed a placeholder clone URL, added a live-example link for credibility, and — the one you flagged — added the philosophical "why opinionated" section explaining the design intent, not just the mechanics.
Claude, How do we know it's "ready"?
Not because it's perfect — because the specific risks of going from private to public were addressed: nothing sensitive leaks, nothing advertised is a lie, the code that runs in a browser is pinned/verifiable, there's a license so people are legally allowed to use it, and there's a documented process for outside contributions. That's a different bar than "feature complete."
What we deliberately didn't do, worth naming honestly in a tutorial so readers don't think "ready" means "finished": no automated test suite, no CI pipeline, no dependency vulnerability scan (pip-audit), and the
--oncecron mode mentioned in the README is still unimplemented. Those are legitimate next steps, just not blockers for visibility — they're maintenance quality, not disclosure risk.
Adding collaborators to a Repo (Private)
Now just because its not public - doesn't mean you can't share! The invite system is a bit wonky, very 90's - but you have to remember that this is serious security for keeping your (often valuable) files/code private. So find those settings first:
Once we are in settings, the Collaborators tab becomes available - if you have 2-Factor Authentication github will ask you to confirm before even entering this tab - but once you manage to find the page - its pretty self explanatory.... mostly.
Let's walk through this now, because I have tripped up here before - once you find the page - you can "Add People" - which opens a pretty silly search box that seems to default to people you have never heard of. But assuming you can manage to find the right person (hint: use email), they will appear inside the box "Pending Invite".
The trick comes in with this "copy link" widget - just grab this immediately and force it on them in DMs - github emails are notoriously "spammy" and there is no guarantee that this person will even see the invitation email to consider accepting unless you do step 3 in the image above.
Github Repo's are Useful
In my next post I hope to talk about one or more other useful features that github offers - whether you are a coder or not - github (and file sharing platforms like gitlab) are on the forefront of human-ai interaction.
As for the DHF/grant accountability angle — public (and private, shared) repos act as receipts for
Public = Collabs
While private repos can be shared with specific people - real magic becomes available with public repos - where "strangers on the internet" can Add Issues, Comment, and suggest PRs. Private repos can't receive that kind of unsolicited goodwill - and the spirit of open source has always exuded a hippy vibe: "We are happy to review real efforts from complete strangers".
How is this changing in the age of AI? More on that soon - but I am not a doomer. In fact, I am optimistic that I am learning (and now teaching!) essential modern skills for a future that gives me hope.
Entering the Danger Zone
So with that said and done, let's "do it", and get back to the general settings page, scroll ALL THE WAY down to the bottom, and dive into the "Danger Zone":
I suppose by being at the top, Changing Visibility is the least dangerous option in the danger zone, but github has set this up to make sure you are "really very certain first" before you click these buttons, including multiple confirmation screens.
But once those buttons are clicked, indeed anyone - EVEN YOU! - can check out my Token Price Widget project at https://github.com/AlexTrapp/token-price-widget