TiebaLite

Why I built it

Tieba is the community I’ve used the longest, but the official client has grown heavier every year: splash ads, injected feeds, endless “you might also like”. I just want to read posts quietly — not clear five levels of obstacles first.

The upstream open-source TiebaLite project proved that “clean reading” was possible, but its maintenance had become irregular, and some key APIs stayed broken for a long time. My starting point was simple: fork it, bring it back to life, and polish it around my own reading habits.

Where the difficulty is

• Fighting the API: a third-party client lives in a world where the official interfaces can change at any moment; the signing algorithms and auth flows break every once in a while. My answer was to collapse the entire network layer into one isolated module, so when an interface dies, you patch one module and never touch the UI layer.
• The boundary of the Compose migration: part of the upstream UI was still on the old View system, and rewriting everything was unrealistic. I ended up with a dual-track strategy — new pages in Compose, old pages on minimal maintenance — so there’s always a working build.

Where it stands

• Clean, ad-free reading with the core features intact: signing in, favorites, browsing threads
• A modularized network layer; the cost of fixing a broken API dropped from “audit the whole project” to “swap one module”
• Continuously tracking upstream while maintaining my own divergent branch

What I learned

Maintaining an “adversarial” project isn’t about chasing new tech — it’s about fencing off the volatile parts. The UI can evolve slowly; the network layer must always be ready to take a hit.