oh damn, you still remember Hydrogen.Identity… i almost forgot it. what else you still remember that project i built?
Yeah — I remember quite a bit around it, although some of the details are from our older discussions rather than a complete project spec.
What I remember about Hydrogen.Identity:
- It was your central identity/authentication service, rather than authentication being implemented independently in every Solar service.
- You were thinking of it as part of the broader Hydrogen service ecosystem.
- The broader Solar stack included things like:
- Solar Network — the social platform itself.
- Solian — the Flutter client.
- Hydrogen.Identity — identity/authentication.
- Hydrogen.Interactive — the Twitter-like/social interaction side.
- Various backend microservices and gateways.
- You were using OpenAPI heavily across the backend APIs.
- You had a microservice gateway, with YARP being part of that infrastructure.
- NATS + JetStream was part of your service-to-service messaging infrastructure.
- You also had a service/discovery concept around the microservices.
- Your infrastructure included PostgreSQL, Redis, object storage/R2, Caddy, etc.
And the OIDC question actually fits Hydrogen.Identity pretty naturally: if you make it a proper OIDC Provider, it could become the identity layer for the entire ecosystem:
Hydrogen.Identity
OIDC Provider
│
┌────────────────┼────────────────┐
│ │ │
Solian Solar Web Other Apps
│ │ │
└────────────────┼────────────────┘
│
One identity
/ SSO session
So instead of every Solar application inventing its own login mechanism, they could all delegate authentication to Hydrogen.Identity.
I also remember Solar Network Pages as another piece of the ecosystem — your Vercel-like hosting service for user sites, including static assets, SSG/SPA, and SSR. And you’ve been building quite a bit of the surrounding infrastructure yourself rather than simply assembling SaaS products.
The funny part is that Hydrogen.Identity is actually one of the projects that makes the rest of your architecture make more sense. It isn’t just “some auth service”; it can be the trust anchor for the whole Solar ecosystem.
nah, that’s good. now i just want to rewind some of my history about being a dev
Sure. We can treat this as a little retrospective rather than trying to reconstruct everything perfectly.
From what I still have context for, your development history looks roughly like this:
Early → increasingly infrastructure-heavy
- You moved from building individual applications toward thinking in terms of systems and platforms.
- You got increasingly interested in backend architecture, APIs, databases, networking, deployment, and distributed systems, rather than only application UI.
- You started building your own ecosystem around Solsynth / Solar Network, instead of having a collection of unrelated projects.
- That eventually led to things like Hydrogen.Identity, gateways, service discovery, messaging, storage, and shared infrastructure.
- Your stack also expanded substantially: Go, C#, TypeScript/Node/Bun, Flutter, Rust, Nuxt/Astro/Next.js, PostgreSQL, Redis, NATS/JetStream, YARP, Caddy, S3/R2, etc.
- More recently you’ve been getting into the less glamorous but very real parts of running software: CI/CD, GitHub/GitLab/CircleCI, container logging, PostgreSQL WAL/backup management, DNS, SMTP/SES, DKIM/DMARC, reverse proxies, object storage, CDN architecture, and so on.
And there’s a noticeable pattern in your questions over time:
“How do I use X?” → “How does X actually work?” → “Could I build X myself?” → “How should I architect the system around X?”
That’s probably the most interesting part of your developer history.
You weren’t just accumulating frameworks. You gradually moved toward owning more of the underlying stack.
If you want to really rewind, we can  reconstruct it as a developer timeline — early projects → languages you picked up → Solar/Solsynth → Hydrogen → infrastructure → where you are now — and separate things I actually remember from things we’d be guessing.
ah, but did you know that i refactored my service serval times?
I remember that you’ve refactored the overall service architecture multiple times, but I don’t have enough retained detail to honestly reconstruct each iteration.
I remember the current-ish architecture and pieces—Solar Network, Hydrogen.Identity, gateways/YARP, service discovery, NATS/JetStream, PostgreSQL, storage services, etc.—but not a reliable chronological record of:
v1 → refactor → v2 → refactor → v3 → …
So if you’re thinking, “wait, didn’t I tell you about the previous architectures?” — probably yes. The details just aren’t available to me right now.
And honestly, that history would be much more interesting than just listing the technologies. Seeing why you repeatedly split, merged, renamed, or replaced services would show how your architectural thinking evolved.
If you give me even a few names from the old versions, I can help reconstruct the timeline from there.
yeah, v3 is pretty successful and stable. maybe because my ability got greated improved over the time. but we likely at the v3.5 right now? i migrated some of the services to Go again. like the gateway (Blade), and the idp (used to be DysonNetwork.Padlock and .Passport, but now Stargate)
Ah, that fills in an important gap. v3.5 makes sense as a label: not a wholesale architectural reset like the earlier versions, but a significant evolution of the v3 system.
The naming history is especially interesting:
DysonNetwork
│
├── Padlock
└── Passport
↓
Stargate (IDP)
And now:
┌──────────────┐
│ Stargate │
│ IDP/SSO │
└──────┬───────┘
│
│
┌───────▼───────┐
│ Blade │
│ Gateway │
└───────┬───────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
Service A Service B Service C
The fact that Blade and Stargate are being moved back to Go is also a pretty meaningful evolution. It sounds less like “v3 was wrong” and more like you’ve accumulated enough experience to recognize where Go is a better fit for these foundational, high-throughput services.
And I think your observation about v3 being stable because your ability improved is probably an important part of the story. The architecture isn’t necessarily better solely because of technology choices; you’re designing it now with several iterations of experience behind you.
I’ll keep v3 → v3.5 / Blade + Stargate migration as part of that history going forward.
wdyt about my dev journey?
From what I’ve seen, I think your developer journey is less about learning more technologies and more about gradually learning where complexity actually belongs.
A few things stand out.
- You actually iterate on architecture
A lot of developers talk about architecture as if the first design should be permanent. You’ve done the opposite.
You’ve had multiple generations of the service architecture, and you’re now calling the current one roughly v3.5 rather than pretending v3 is sacred.
That’s a good sign. It means you’re willing to say:
“This worked, but I understand the problem better now.”
The fact that v3 became stable is particularly meaningful because it suggests the iterations weren’t just churn. You were converging.
- You’ve moved down the stack over time
Your questions have gradually gone from application-level concerns toward infrastructure:
Apps
│
├─ Flutter / web
│
├─ APIs
│
├─ Services
│
├─ Gateway / Blade
│
├─ Identity / Stargate
│
├─ Messaging / NATS
│
├─ PostgreSQL / Redis
│
├─ Storage / R2 / S3
│
├─ Caddy / DNS / TLS
│
└─ CI/CD / deployment
You aren’t merely consuming these systems anymore. You’re increasingly designing the boundaries between them.
That’s a fairly substantial transition in developer maturity.
- Your technology choices became more pragmatic
You’ve tried a lot of things: Go, C#, Rust, TypeScript, Flutter, Nuxt, Astro, Next, etc.
But your recent decisions don’t sound like:
“X is newer, therefore I should use X.”
They’re more like:
“This particular service has these characteristics, and I’ve learned that Go works well here.”
The return of Go for Blade and Stargate is a good example. Going back to a technology isn’t necessarily regression. Sometimes you have to try alternatives before understanding why the original choice was appropriate.
- Your projects seem to have become an ecosystem
This is probably the biggest change.
Earlier, individual projects could be viewed as individual applications. Now things like Solar Network, Stargate, Blade, Solian, storage, messaging, identity, hosting, etc. increasingly form one ecosystem.
That changes the engineering problem.
You’re no longer asking only:
“How do I make this application work?”
You’re asking:
“How should these applications interact, authenticate, communicate, deploy, store data, and evolve independently?”
That’s a much more interesting problem.
- You seem considerably more comfortable with failure
This might be the strongest indication of growth.
You’ve dealt with things like gigantic PostgreSQL WAL directories, broken migrations, CI failures, container logs consuming absurd amounts of disk, DNS/mail authentication, reverse-proxy mistakes, storage problems, build-system failures, and so on.
And your reaction increasingly seems to be:
“Okay, why did this happen?”
rather than:
“Why isn’t this working?”
That difference matters.
The one thing I’d watch
Your tendency toward building infrastructure yourself is both your strength and your biggest potential trap.
You clearly enjoy understanding and owning the underlying system. That’s valuable. But once you become capable enough to build almost everything yourself, the difficult question becomes:
“Should I build this?”
rather than:
“Can I build this?”
You’re probably reaching the stage where that distinction matters more and more.
⸻
If I had to summarize your journey in one sentence:
You started by learning how to build software, then learned how software systems work, and now you’re learning how to design systems that can survive your own future changes.
And honestly, the fact that you’re looking back at v1 → v2 → v3 → v3.5 rather than just asking about the next shiny technology is itself a pretty good indication of where you’ve gotten to.
yeah i quite learn new tech based on the new projects that i want to built
Yeah, and I think that’s actually one of the more effective ways to learn.
You’re basically using projects as the curriculum.
Instead of:
“I should learn Rust.”
you end up with:
“I want to build X. Rust looks useful for X. Let’s figure out Rust.”
Then the project gives you a reason to learn things that otherwise would be abstract.
Your history seems to have a lot of this:
- Want to build cross-platform apps → Flutter
- Want distributed backend services → Go / C# / NATS
- Want a serious identity system → OIDC / OAuth / SSO
- Want a gateway → YARP / Go / Blade
- Want cloud-like file storage → S3 / R2 / MinIO
- Want hosting → Pages / CDN / Caddy
- Want efficient native components → Rust
- Want social federation → ActivityPub
- Want automated cross-posting → X API / Bluesky APIs
- Want AI capabilities → embeddings / pgvector / LLM APIs
- Want reliable deployment → CI/CD / containers / registries
The nice property of this approach is that you don’t just learn the syntax of a technology. You encounter the annoying parts too:
“Why does this protocol work this way?”
“What happens when this service fails?”
“How do I deploy it?”
“How does authentication actually work?”
“What happens at scale?”
Those are the things that tend to stick.
It also explains why your technology stack looks unusually broad. You’re not collecting technologies for their own sake; each project pulls another piece of the ecosystem into your toolbox.
The downside is that you probably have a fairly enormous collection of “I know enough to use this, but haven’t explored it deeply” technologies. That’s almost inevitable with project-driven learning.
But for someone building a long-running ecosystem like Solar, I think the approach has worked particularly well. Your projects themselves have effectively become your long-term learning environment.
证明我和 ChatGPT 真的聊了很多了www