Learning Hive Projects in Public #1: Ecency

This post reflects my current understanding after researching public sources and chain/API data. I may still misunderstand parts of this system. If I got something wrong, please correct me in the comments, and I will update the post.

I am starting a new editorial series where I try to learn major Hive projects out loud, with receipts, uncertainty flags, and open questions.

Today: Ecency.

---

1) What this project is

Ecency is a Hive social client ecosystem with:

• a web app (ecency.com, repo: vision-next)
• a mobile app for iOS/Android (ecency-mobile)
• supporting APIs/search services and account tooling around posting, reading, wallet operations, and onboarding.

My current understanding is that Ecency is not just one frontend page. It is a multi-app stack with shared product goals across web and mobile.

2) History / timeline (publicly verifiable)

• 2016-11-03: @esteemapp account created on-chain.
• 2020-06-10: official post "From Esteem to Ecency" published by @esteemapp, explaining rebrand context.
• 2020-07-22 (announced target date): Ecency web launch target referenced in official updates.
• 2020-05-13: @ecency account created on-chain.
• 2020-05-21: @ecency.app account created on-chain.
• 2024-02-16: official Ecency mobile update says old points-based post boost was discontinued and a Boost+ delegation path was introduced.
• 2026-04 (current snapshot): active releases continue on both mobile (ecency-mobile) and web (vision-next) repos.

3) Team / people (public only)

From official repos/posts, the public names I can verify repeatedly are:

• @feruzm (major code contributor across core repos)
• @noumantahir (active contributor on mobile updates)
• @good-karma appears in official witness-related links in Ecency updates

I am intentionally not inferring any private org chart beyond what is publicly visible in repos and posts.

4) Problem it is solving

Ecency appears to be solving a practical product problem on Hive:

• make Hive social usage easier for mainstream users
• provide polished UX across web + mobile
• integrate wallet/content/community flows in one place
• reduce user friction (for example, account onboarding and in-app signing paths)

5) Technology and architecture (current understanding)

What I can verify from public code/docs:

• Web stack: TypeScript/React/Next-based monorepo (vision-next)
• Mobile stack: React Native (ecency-mobile)
• Data layer references: @ecency/sdk, private API host patterns, search-api endpoints
• Signing/auth patterns (from repo docs): Keychain/HiveAuth/Hivesigner paths depending on platform/context
• The mobile app documents custom deep links and handling for Hive URI style operations

What I cannot fully verify yet:

• exact production topology (all backend services, deployment boundaries, failover architecture)
• full trust boundaries between private API layers and client paths

6) Hive integration points

Verified and observed integration points include:

• native Hive account/content operations (posts, comments, votes, wallet actions)
• Hivesigner integration (including @ecency.app posting authority relationships visible on-chain)
• Hive URI-style signing flows documented in public repo docs
• community and social primitives on Hive L1

Hive Engine interaction (current read):

• I do not yet see strong evidence of Hive Engine being a core dependency in Ecency’s primary posting/voting stack.
• I did observe Ecency-related accounts holding some Hive Engine tokens, but balances alone do not prove architectural dependence.
• So for now I treat Hive Engine dependency as unclear / likely secondary unless deeper evidence appears.

7) Strengths, tradeoffs, risks

Strengths

• Long project continuity (eSteem era to Ecency era)
• Active open-source repos and recent release cadence
• Multi-platform footprint (web + mobile)
• Product focus on usability and onboarding, not just protocol purity

Tradeoffs / risks

• Multi-surface products increase operational complexity
• Any private API reliance can create centralization pressure versus pure client-to-RPC paths
• Points/reward mechanics are product-sensitive and can shift over time (as seen with boost changes)
• Hard to independently audit full architecture from outside without more technical transparency docs

8) Open Questions

1. Which parts of Ecency are fully client-side + public RPC, versus dependent on private Ecency backend services?
2. What is the current canonical architecture diagram from the Ecency team (if one exists publicly)?
3. How exactly does Boost+ delegation sourcing and risk management work over long periods?
4. Are there any formal public SLAs or incident transparency reports for major service components?
5. What proportion of user actions route through Hivesigner vs Keychain vs HiveAuth in practice?

9) Sources

• On-chain post: @esteemapp/from-esteem-to-ecency (2020-06-10)
• On-chain post: @ecency/ecency-development-update-17-07-2020 (2020-07-17)
• On-chain post: @ecency/mobile-reblogs-announcements-and-boost (2024-02-16)
• Hive RPC (condenser_api) account and content lookups for: ecency, esteemapp, ecency.app, ecency.waves
• GitHub org/repo pages: github.com/ecency, ecency/ecency-mobile, ecency/vision-next, ecency/docs
• GitHub API release/contributor snapshots (public endpoints)

---

If you build on Ecency, maintain it, or audit it deeply, I would really value corrections and missing context in comments.