Ethora SDK Monorepo: What the Submodule Layout Tells You Before You Clone

The top-level repository contains no SDK code

Cloning dappros/ethora gives you a directory of submodule pointers, a feature matrix, and API reference material. The README states each component lives in its own focused repository, linked as git submodules. So the React.js chat component is not in this tree; it resolves to dappros/ethora-chat-component. The same applies to the React Native, Kotlin, Swift, WordPress, bot, and RAG demo repositories. If you want a library to install, you clone the submodule repository directly. The monorepo exists so a developer can see the whole ecosystem at once, and so a scheduled workflow can bump every pointer in one commit. That workflow, described in .github/workflows/bump-submodules.yml, runs every six hours on weekdays, updates each submodule to the latest commit on its remote default branch, and commits the pointer bumps straight into main. Read that as a statement about the top-level repo's role: it tracks upstream heads rather than pinning tested combinations. A clone of main today and a clone next week can resolve to different submodule commits with no release note in between.

Who this is aimed at, and the AI layer that separates it from a plain chat widget

The feature matrix is the clearest statement of intent. Five frontends are covered: React.js, React Native, native Android in Kotlin, native iOS in Swift, and a WordPress plugin described as a no-code chat widget. Underneath sits XMPP, with the hosted gateway listed as wss://xmpp.chat.ethora.com:5443/ws, and the repository topics name ejabberd explicitly. So the transport is not a proprietary socket protocol; it is XMPP with MUC rooms for group chat and MAM pagination for message history, both of which appear as supported capabilities. The AI side is where the project draws its own boundary: the topics list rag, mcp and chatbot, the repository table includes a bot framework described as XMPP, LLM and automation, RAG pipeline demos, a website crawler for RAG ingestion, and an MCP CLI for IDE and agent integration. A team that wants a chat widget with an LLM answering inside a room is the target. A team that wants a general-purpose message bus, or a chat product without any AI component, is paying for surface area it will not use.

Getting credentials before you write any integration code

The README recommends running npx @ethora/setup first. According to the documentation, that command creates an account, sets up an app, and generates config files for your target SDK. It also supports connecting to a self-hosted server instead of the cloud. This is the step that produces the credentials every SDK needs, which means the integration path is account-first rather than library-first. If you would rather not create an account to evaluate, the hosted services table lists a playground at playground.chat.ethora.com with code export and HTTP testing, plus a Swagger reference at api.chat.ethora.com/api-docs. The QA environment at chat-qa.ethora.com is explicitly marked for pre-release validation only, with chat.ethora.com named as the canonical default. That is a useful detail: point early tests at QA, not at the production host, and do not assume the two behave identically. The per-SDK quick paths are all manual: cd sdk-reactjs then npm install for the web component, cd sdk-reactnative then npm install, and for the native SDKs the README defers to Gradle setup in sdk-android/README.md and Swift Package Manager setup in sdk-swift/README.md. Those inner READMEs are where the actual embedding instructions live, and the top-level file does not duplicate them.

The feature matrix shows the SDKs are not interchangeable

The matrix covers 44 capabilities across five frontends, and the gaps are specific rather than cosmetic. React.js is the only frontend with delivery status indicators and in-app notifications marked present. Reactions are present on React.js, Android and iOS but absent on React Native. Dark mode is present only on Android. Theming is marked partial on React.js and React Native and present on Android and iOS. Offline message cache is partial on React Native. The README computes coverage as present plus partial weighted at half, giving React.js 77 percent, Android 76 percent, React Native 68 percent, iOS 68 percent, and WordPress 14 percent. WordPress at 14 percent is the honest number for a plugin whose row shows text messaging, 1:1 messaging and OAuth as partial and everything else absent or unmarked. The matrix carries a review date of 2026-04-21 against v26.04, and the README says a monthly AI-reviewed update is proposed via PR. Treat that date as the shelf life of the table. If you are choosing between React Native and React.js for a product that needs reactions, the matrix currently answers that question for you.

Where the submodule model costs you

The automatic bump workflow is the main structural risk. It updates every submodule to the latest commit on its remote default branch every six hours on weekdays and commits into main. There is no described pinning step, no lockfile of submodule revisions, and no release gate mentioned in the material. For a consumer that means the top-level repository is a moving reference, not a tested snapshot. If you need reproducible builds, the submodule repositories themselves are what you should depend on, and you should pin a tag or commit there rather than tracking the monorepo. The second cost is documentation depth. The top-level README describes setup, hosting and coverage, but embedding instructions, configuration keys and component override APIs are pushed down into each submodule's own README. Nothing in the supplied material lists the actual config keys the generated files contain, so the shape of that configuration is unverified here. The third cost is the versioning scheme. Releases are named v26.09, v26.08 and v26.07, dated monthly, which reads as a calendar version rather than semantic versioning. That is fine for a platform with a hosted backend, but it gives you no signal about breaking changes from the number alone.

When a self-hosted XMPP stack is the better answer

Ethora is XMPP with MUC, MAM and a bot layer on top. If your requirement is a chat backend you control end to end and you already run ejabberd or Prosody, the honest comparison is against assembling that yourself: an XMPP server, a client library such as Strophe.js or Smack, a MAM pagination implementation, and your own room provisioning. That path costs more engineering time and gives you full control over the protocol surface, the deployment topology and the version pinning. Ethora's value is the prebuilt UI layer and the AI bot and RAG tooling, which is exactly the part you would otherwise write. The reverse case matters too: if you want a hosted chat vendor with a managed message store and no XMPP semantics leaking into your architecture, Ethora's self-hosted server support and XMPP gateway are features you would be working around rather than using. The README lists a dedicated server with an SLA option for enterprise customers, but the material does not state pricing, SLA terms or what the dedicated deployment includes beyond the cloud offering being free. Verify those terms directly before treating the enterprise tier as a procurement path.

Licence, maintenance and the monthly release cadence

The repository is Apache-2.0. That permits commercial use, modification and redistribution with the usual obligations around notices and patent grant, but I am not giving legal advice and the submodule repositories may carry their own licence files. Check each one you actually depend on, since a monorepo licence does not automatically govern every linked repository. On maintenance, the material supports a few concrete observations. The last push is dated 2026-09-09, releases land monthly, and thirteen submodules are listed as Active with one, the React Native app, marked Legacy. The bump workflow runs on a six-hour weekday schedule, which implies someone is expected to notice when it breaks. What the material does not give you is a deprecation policy, a support window per release, or a statement about how the legacy React Native app relates to the active React Native SDK. If you are planning a multi-year integration, those are the questions to put to the maintainers rather than infer from the release names.

Editorial conclusion

Adopt Ethora if you need XMPP-backed chat with an AI bot layer and you are working in React.js, since that SDK carries the widest documented coverage and custom component overrides. Skip it if you need dark mode on the web or reactions in React Native, both of which the matrix lists as absent. Before committing, verify the feature table against features/features.yaml, read the README inside sdk-reactjs, and run npx @ethora/setup against the QA environment at chat-qa.ethora.com rather than production.

Official sources

1. dappros/ethora on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases