Firebase recorded 3,044 first app opens on Aug 18 and 5,947 on Aug 19, while invite codes were still required. The server stopped requiring codes on Aug 20; first opens stayed high at 5,189, the invite screen largely disappeared, and more installations reached account creation, the feed, and successful publishing. Production stayed available through the surge.
There is no single event in the available data that means “a person completed Divine signup.” This report therefore keeps app measurements, public Nostr activity, client failures, and infrastructure health separate.
A “first open” is the first launch of one app installation, including reinstalls. “Active installations” sent at least one analytics event. Screen counts mean an installation reached that screen; they do not prove the step was completed.
Nostr is the open network Divine uses. An account is identified by a public key. ClickHouse records public profiles, posts, follows, reactions, comments, and other signed activity from Divine’s data pipeline—not only actions performed in the Divine app.
Crashlytics records fatal and nonfatal mobile failures. Sentry records grouped backend and web errors. Repeated reports can come from one installation, so event totals are not the same as affected people.
Divine app version 1.0.20 produced nearly all first opens during the surge. iOS contributed 3,868 of 5,947 first opens on Aug 19; Android contributed 2,079. The arrival peak cannot be attributed to invite removal because it happened while codes were still required.
Definition: Firebase first_open fires when an app installation launches for the first time. It includes reinstalls and does not prove that a person created or finished creating a Divine account. This is a first-party measure of new app arrivals, not a signup count.
First opens jumped from 299 to 3,044 while the server still required invite codes.
3,868 first opens were on iOS and 2,079 were on Android.
The server changed to open mode during the UTC day, so Aug 20 contains activity from both sides of the change.
These are distinct Firebase installation IDs that displayed each screen during the UTC day. They are not a sequential conversion funnel: one installation may appear in several boxes, and someone can start on one day and continue on another.
5,281 on Aug 19 → 1,464 on the Aug 20 transition day → 51 on Aug 21.
2,344 on Aug 19 → 4,301 on Aug 20. Reaching the screen is not proof of account completion.
1,525 on Aug 19 → 2,919 on Aug 20.
Before the surge, 14.5% of installations that first opened from Aug 11–17 sent another Firebase event on the next UTC day. The rate was 15.3% for Aug 18, 12.7% for Aug 19, and 15.9% for Aug 20. Aug 21 currently reads 18.8%, but its next-day window uses partial Aug 22 data.
Definition: the denominator is app installations that fired first_open on a given UTC day. “Active next day” means the same Firebase installation sent any analytics event on the following UTC day. It measures installation-level return to the app, not account retention and not whether someone posted. * The Aug 21 group uses an incomplete Aug 22 return window.
755 of 5,947 first-open installations were active again on Aug 20: 12.7%.
824 of 5,189 first-open installations were active again on Aug 21: 15.9%.
Firebase identifies installations, not people or Nostr accounts. Reinstalls and multiple devices can create more than one identifier.
Firebase and ClickHouse agree on the direction but count different things. Firebase records what instrumented Divine app installations reported. ClickHouse records public Nostr activity that reached Divine’s analytics pipeline, including activity from other clients.
60 installations on Aug 16 → 239 on Aug 20 → 209 on partial Aug 22.
95 Nostr accounts on Aug 16 → 259 on Aug 20.
179 on Aug 16 → 497 on Aug 20 → 489 on partial Aug 22.
266 on Aug 16 → 611 on Aug 20.
The earlier draft treated newly observed Nostr profiles as if they were app signups and invented labels for subsets. That was wrong. The chart remains useful only as a description of public profile records entering the analytics pipeline.
Definition: a Nostr profile record is public account metadata seen by Divine’s analytics database. It can be created by Divine, another Nostr client, an import, or automation. On Aug 21, 1,236 of 1,987 records listed atomstr.data.haus in the profile address field and arrived in a concentrated batch. We report that exact fact; we do not label the other records “human.”
The infrastructure snapshot was taken near 22:27 UTC on Aug 22. It describes server capacity at that moment, while request/error totals cover UTC days. It does not describe every client-side experience.
“Ready” means Kubernetes could schedule and run workloads on every node. The busiest node was at 65% CPU.
A pod is one running API instance. The snapshot showed three running, with room for the autoscaler to add up to twelve.
Each relay pod had about 130 live connections; the connection-based scale threshold was 1,500 per pod.
ClickHouse was about 72 seconds behind live Nostr traffic at 22:16 UTC.
| UTC day | Media uploads | Divine names | Identity checks | Moderation calls |
|---|---|---|---|---|
| Aug 20 | 402,617 / 0 | 329,476 / 1,104 | — | 10.27m / 1,926 |
| Aug 21 | 797,428 / 0 | 389,449 / 20 | 157,532 / 0 | 16.54m / 1,660 |
| Aug 22* | 513,690 / 0 | 165,895 / 0 | 84,550 / 0 | 12.66m / 1,335 |
The values are requests / Worker execution errors. Moderation errors were 0.0188% of calls on Aug 20, 0.0100% on Aug 21, and 0.0105% on partial Aug 22. The Divine name service recorded 1,104 Worker errors on Aug 20, 20 on Aug 21, and none on partial Aug 22.
Crashlytics is the mobile failure source. Sentry covers Funnelcake, Divine Connect, Keycast, and web projects. Counts from these systems are not directly comparable: Crashlytics counts events and affected installations; Sentry groups similar server/web events into issues.
Distinct mobile installations reported at least one fatal event: 3 Android and 25 iOS. The same UTC day had 7,932 active iOS/Android installation IDs in Firebase.
Distinct installations reported any fatal or nonfatal Crashlytics event: 197 Android and 218 iOS. One installation can report many events.
Issue groups were active in the checked projects: 47 Funnelcake, 2 Divine Connect, 4 web, and 0 Keycast. This is a count of grouped error types, not occurrences.
On Aug 20 Crashlytics received 1,373 reports: 51 fatal events and 1,322 nonfatal events. The largest nonfatal families involved view-event publishing and uncaught Flutter zone errors.
Active Funnelcake groups included feed/list failures and short ClickHouse connection failures around 14:33 UTC on Aug 22. ClickHouse ingestion was current again in the later snapshot.
Firebase still saw 51 installations on invite_gate on Aug 21 and 27 on partial Aug 22. The shipped client could still show that screen when its configuration request failed; the analytics data cannot separate that path from stale sessions or navigation.
Firebase Analytics: BigQuery dataset analytics_505815521. Used for first opens, active installations, sessions, screens, successful/failed publishing, and next-day app activity. Daily boundaries were recalculated from event timestamps in UTC.
Firebase Crashlytics: BigQuery dataset firebase_crashlytics, Android and iOS batch plus realtime tables, deduplicated by Crashlytics event ID. Used for fatal/nonfatal reports and affected installation counts.
Sentry: Divine organization projects funnelcake, divine-connect, javascript-react, and keycast. Used for issue groups active from Aug 11 through Aug 22. Sentry does not contain the Divine mobile project.
ClickHouse: Divine production Nostr analytical views. Used for public profile records, video posts, video authors, follows, reactions, comments, and accounts authoring any Nostr event.
Divine Brain: used for the operational request/error ledger and to locate the Aug 20 invite-mode change in Divine Mobile issue #8000. Brain document 3CCABF801C7F2419C43E61C7A5.
Live production: Kubernetes, autoscaling, deployment, and metrics state captured Aug 22 around 22:27–22:29 UTC. A later state can differ from this snapshot.
No direct signup-complete event: the available Firebase event list has first_open and onboarding screen events, but no single first-party event proving that account creation completed. The report therefore does not state a signup count.
Aug 22 is partial: Firebase, ClickHouse, and request data were still arriving when the snapshot was taken. Do not compare Aug 22 totals with full days without adjusting for the shorter window.
openvine-co.