This policy explains what La Corporation Tempo Inc. collects when you use Tempo Music, why, who else touches it, how long we keep it, and the controls you have. Every section starts with a plain-words summary, then gives the precise details. If a summary and the details ever seem to disagree, tell us (that is a bug in the policy, and we treat it like one).
Our stance, stated up front: we collect the minimum we can justify to you, we explain every practice next to the data it concerns, and we never bundle your consent into account creation beyond what is strictly necessary to run the service.
1. Who we are and how to reach us
In plain words: Tempo Music is made by a small company in Québec, Canada. Two email addresses reach us; one of them goes to the person legally responsible for your data.
Tempo Music is operated by La Corporation Tempo Inc., a corporation constituted under the laws of Québec, Canada (Business Number 771577368; NEQ 1180432917).
- Privacy matters: privacy@tempomusic.app. This reaches our person in charge of the protection of personal information (our CEO), as designated under Québec's Act respecting the protection of personal information in the private sector ("Law 25").
- Everything else: support@tempomusic.app
Depending on where you live, this policy is written to meet Québec Law 25 and Canada's PIPEDA, and, for testers and users in the European Union, the GDPR (see Section 8.5 for your EU-specific rights and the legal bases we rely on).
2. The short version
- Your posts, likes, follows, and profile are public, not just on Tempo Music but on the open AT Protocol network. Anyone, including services unrelated to us, can copy and display them. Deletion on our side is real but cannot reach every copy others made. Section 3 explains this honestly.
- To create an account we collect four things: handle, invite code, email, password. No date of birth, no phone number, no real name.
- Connecting Apple Music or Last.fm is optional, read-only from your perspective (we never post to those services or modify your library), and disconnectable at any time. Sharing from Spotify or Shazam sends us a link, never your account.
- Analytics run on our own event catalog, published in full in Section 4.4 and generated from the same file our code uses, so the list in this policy cannot drift from what the app actually does. During early access, analytics are on by default and this is disclosed to every invited tester; an opt-in consent system (iCARE) gives you real per-category refusal, and a genuine global opt-out exists. Exactly two small events are consent-exempt, and Section 4.4 tells you precisely which and why.
- We never collect for analytics: what you write in posts, your precise location, or where you heard about Tempo.
- Your data lives on servers in Canada; analytics are processed by PostHog in the EU.
- Account deletion: content deletion is issued immediately, identified analytics are erased within 30 days, and your consent preferences are erased on day 0.
3. Your content lives on an open network
In plain words: Tempo is built on the AT Protocol, like Bluesky. Public means public across the whole network, not just inside our app. We can delete what we host; we cannot force strangers who copied your public posts to delete their copies. This is the single biggest difference from a centralized app, and you should decide what to post knowing it.
Tempo Music is a client of the AT Protocol, an open, decentralized social networking protocol. Your account is anchored to a DID (decentralized identifier) and a handle, and your content (posts, ratings, reviews, likes, follows, profile) is stored as records in a personal data repository, hosted either on our PDS (personal data server) or on an external PDS you choose (for example a Bluesky account or a self-hosted server).
What this means for your privacy, concretely:
- Public records are replicated. Relays, feed generators, other AT Protocol apps, and independent archivers continuously read and copy public records. This is how the network functions; it is not an accident or a leak.
- Deletion is honest but bounded. When you delete content or your account, we delete the records from every system we control and emit the protocol's deletion events, which well-behaved network participants honour. Participants that ignore them are beyond our technical reach. We will never pretend otherwise.
- Migration is your right. If we host your account, you can move it (identity, content, and all) to another PDS provider at any time using the protocol's migration mechanism. We do not obstruct migrations. This is also your most complete form of data portability (Section 8.3).
- External PDS users: if your repository lives on a server you or a third party operates, that operator, not Tempo, stores your content and credentials, and its own privacy practices apply to what it holds.
Not everything is public. The following are private and never written to your public repository: your email address, your password, your session data, your music service connections and tokens, your analytics consent preferences, and your moderation reports.
4. What we collect and why
Each subsection lists what we collect, why we collect it, and the control you have, all in one place rather than in an annex.
4.1 Account and sign-in
In plain words: four fields to sign up, none of them your identity. Your account creation date doubles as your acceptance of the Terms and this policy. We deliberately don't keep a separate acceptance dossier.
When you create an account through Tempo's native signup we collect exactly:
| Data | Why | Your control |
|---|---|---|
| Handle | Your public name on the network; required by the protocol. | Changeable; public by design. |
| Invite code | Early access is invitation-only; the code validates your invitation. | Consumed at signup. |
| Email address | Account recovery and essential service messages. Never published, never used for marketing without separate consent. | Correctable in settings; erased with your account. |
| Password | Authentication. Stored only in hashed form; we cannot read it. | Changeable at any time. |
We do not collect your date of birth (Section 5). If an age confirmation is shown at signup, it is a self-certification checkbox ("I am at least 13 years old"); we store only the fact that you checked it, nothing about your age itself.
Your account creation timestamp is stored and serves as the record that you accepted the Terms of Service and this Privacy Policy, both of which are linked from the signup screen. There is no separate acceptance record.
If you sign in with an account hosted on an external PDS, we receive your DID, handle, and the session data needed to act on your behalf at your instruction; your credentials stay with your host.
4.2 Your content
In plain words: we host what you publish so the network can see it; that's the product. Drafts stay on your device.
Posts, ratings, reviews, images you attach, and your profile are stored in your data repository (Section 3) and are public. Unpublished drafts remain on your device and are not transmitted. We do not read, mine, or analyze the text of your posts for analytics or advertising (Section 5).
4.3 Music service connections and sharing
In plain words: connect Apple Music or Last.fm and we read your listening history so you can post about it. That's all we do with it. We never write to your music accounts. Sharing from Spotify or Shazam sends us a link, not your account.
Connections (Apple Music and Last.fm; others may follow):
- Connecting happens through each service's own authorization flow. We store the resulting access token encrypted in our infrastructure in Canada, and use it for exactly one purpose: fetching your recently played tracks / scrobbles and related library metadata so you can pick something to post about.
- We never post to, modify, or write anything to your music services. No action happens on those services without you explicitly taking it there.
- Disconnect at any time in settings: we revoke and delete the token and stop all further access immediately. Deleting your account does the same.
- What each service exposes to us is governed by its own permissions screen. Read it; it is the accurate list for that service.
Sharing from other apps (Spotify, Shazam, and system share sheets):
- When you share a song or album into Tempo, we receive the shared link and resolve it to music metadata (via the source's public metadata and MusicBrainz). We receive no account information, no token, and no listening history from the source app.
- The analytics events around sharing (category "Sharing from other apps", Section 4.4) record the kind of thing shared and whether it resolved, identified by entity type and provider, never by your music taste profile.
4.4 Analytics — the full inventory and your controls
In plain words: we measure how the app is used so we can fix and improve it. The complete list of events is below, generated from the same file the code uses. During early access, collection is on by default and every invited tester is told so. Turn on iCARE in settings to get real per-category consent dialogs where refusal actually stops collection. There is a genuine global opt-out. Two small events are exempt from consent; they are named below and nothing else is allowed to join them.
Where analytics run. Events are sent to PostHog Cloud EU (servers in the European Union), through a first-party proxy we operate (ph.tempo.ludos.city). PostHog is our data processor; data does leave our own infrastructure to reach it. (We may self-host analytics in the future; if we do, this policy and its change log will say so.)
The consent model. Every event belongs to one of six consentable categories: Account & onboarding · Post creation · Music service connections · Sharing from other apps · Feed & interactions · App usage, plus one consent-exempt class described below. These category descriptions are contractual: the in-app consent panel and this policy are generated from the same catalog, so they cannot diverge.
Early access stance, stated plainly. During the invitation-only alpha, the master analytics switch is on by default and this is disclosed to every invited tester. A real consent mechanism is a prerequisite to public launch, not an afterthought to it.
iCARE, the opt-in consent system. In settings you'll find a second switch, iCARE:
- Off (default): no consent prompts; collection proceeds silently under the early-access stance above.
- On: each category asks before its first collection, in a blocking dialog where accept and refuse are equally live buttons. Refusal stops that category's collection. A settings panel lets you revisit every decision at any time.
- Consent before collection, mechanically: while a category's answer is undecided (or your consent state hasn't loaded yet after login), its events are held in a bounded buffer on your device. They are transmitted only after you accept; refusing drops them. Nothing leaves your device before your answer.
- Turning iCARE off again erases your recorded per-category choices: after an explicit confirmation, everything becomes active again. The app's confirmation dialog says "everything active again"; this policy says it more bluntly: switching iCARE off deletes your past refusals. Turn it back on and you will be asked afresh.
- Your consent preferences are private per-account data, synced across your devices, never written to your public repository, and erased on day 0 of account deletion.
Catalog evolution rule. A new event added to an existing category inherits that category's consent state. A brand-new category always arrives switched off and is announced in-app before it collects anything.
The one exemption: the last farewell. Refusing every category can reveal a feature-flagged easter egg that offers the real global opt-out during early access. Exactly two events bypass consent, and the exemption is announced inside the dialog itself:
easter_egg_discovered: counts that someone found it;easter_egg_decision: records whether the discoverer kept sharing or took the opt-out (emitted when the dialog closes and on later master-switch toggles by a discoverer).
These are the only data collected from a fully opted-out user. They are flagged consentExempt in the generated catalog, and no other event may ever join this class; adding one would be a change to this policy, not just to the code.
Identity and anonymity. Nothing you do before creating an account is ever linked to you, and pre-account analytics are anonymous, permanently. (The signup_completed event is never linked to the account it created.) If pre-login browsing ships one day, we may offer an opt-in to retroactively link your earlier anonymous session to your account; unless you explicitly accept such an offer, no linking happens. This paragraph reserves the mechanism; it does not promise or perform it.
What analytics never contain. The text of your posts and messages, your precise location, and how you heard about Tempo (acquisition source). See Section 5.
On-device stats. The "fun facts" the app shows you about your own listening and posting are computed locally on your device and never transmitted; they keep working even when you are fully opted out. We built them that way on purpose, as proof that insight for you doesn't require collection by us.
Retention. Raw events are kept for 13 months, then only aggregate statistics survive. When you delete your account, analytics identified to you are erased within 30 days.
Transparency roadmap (intent, not commitment). After alpha we intend to publish a machine-readable analytics manifest (so silent changes to our collection would be externally detectable) and self-published aggregate opt-out rates. Our principle: publish the collector's practices, never the subject's choices.
The event catalog (generated from catalog version 1)
The tables below are generated from the same catalog the app is built from. Listed properties are the maximum an event can carry; optional ones may be absent on a given emission. Every event also carries two common technical properties: app_version (version of the app emitting the event) and environment (development / staging / production).
Account & onboarding (6 events, consentable, refusable under iCARE)
Signup and sign-in funnel: where people start, drop off, and succeed. Never linked to the account that gets created.
| Event | Why we collect it | Properties |
|---|---|---|
onboarding_started | Measure how many people reach the sign-in landing, as the start of the onboarding funnel. | — |
signup_completed | Measure how many signup attempts succeed. Never linked to the new account. | method |
signup_details_submitted | Measure drop-off at the account-creation submit and how often the server rejects a first attempt. Emitted per attempt: is_retry distinguishes re-submissions after a rejection. | is_retry |
signup_failed | Understand where and why account creation fails, using coarse error categories only. | error_category, method |
signup_invite_code_submitted | Measure drop-off between the invite code screen and the rest of the native signup funnel. Emitted per attempt: is_retry distinguishes re-submissions after a rejected code. | is_retry |
signup_started | Measure how many people attempt to create an account. | method |
Post creation (3 events, consentable, refusable under iCARE)
The publishing funnel: opening the composer, attaching music, and whether publishing succeeds.
| Event | Why we collect it | Properties |
|---|---|---|
composer_music_attached | Understand which kinds of music subjects people attach to drafts. | entity_type |
composer_opened | Measure how many people open the post composer, as the start of the publishing funnel. | — |
post_published | Measure whether publish attempts succeed, which side fails, and how long publishing takes. | error_category, outcome, took_ms |
Music service connections (3 events, consentable, refusable under iCARE)
Whether connecting Apple Music / Last.fm works, and where it fails.
| Event | Why we collect it | Properties |
|---|---|---|
service_connect_completed | Measure successful music service connections and their duration. | service, service_kind, took_ms |
service_connect_failed | Understand where music service connections fail, using coarse error categories only. | error_category, service, service_kind, took_ms |
service_connect_started | Measure how many people start connecting a music service. | service, service_kind |
Sharing from other apps (7 events, consentable, refusable under iCARE)
What happens to songs shared into Tempo from Spotify, Shazam, and other apps: received, resolved, published, or dropped.
| Event | Why we collect it | Properties |
|---|---|---|
incoming_share_dismissed | Measure how many incoming shares are abandoned before publishing. | entity_type |
incoming_share_full_sheet_open_drop | Count shares dropped because the composer was already open, to justify fixing that limitation. | — |
incoming_share_metadata_failed | Understand why shared music fails to resolve. | entity_type, failure_kind, provider |
incoming_share_metadata_resolved | Measure whether shared music resolves to something publishable and how. | catalogue_enrichment_source, entity_type, provider, took_ms |
incoming_share_published | Measure how many incoming shares become published posts. | entity_type, has_thought_text, thought_length_chars |
incoming_share_received | Measure how many shares from streaming apps reach Tempo. | entity_type, provider |
incoming_share_unsupported | Understand which unsupported share kinds people attempt, to prioritise support. | provider, raw_type |
Feed & interactions (3 events, consentable, refusable under iCARE)
Coarse engagement actions: opening the feed, liking, replying. Never what the content says.
| Event | Why we collect it | Properties |
|---|---|---|
feed_opened | Measure how often the feed is opened, as the start of the engagement funnel. | — |
post_liked | Measure like activity as a meaningful engagement action. | — |
reply_published | Measure reply activity as a meaningful engagement action. | — |
App usage (1 event, consentable, refusable under iCARE)
How often the app is opened and in what state.
| Event | Why we collect it | Properties |
|---|---|---|
app_opened | Measure how often the app is opened and whether sessions start cold or from the background. | is_cold_start |
The last farewell (2 events, consent-exempt)
The only consent-exempt class: two events around the global opt-out easter egg. See the exemption explanation above.
| Event | Why we collect it | Properties |
|---|---|---|
easter_egg_decision | Learn what discoverers decide: keep sharing, or take the real opt-out. | share_all_kept |
easter_egg_discovered | Count how many users discover the opt-out easter egg at all. | — |
SDK technical events. The PostHog SDK additionally emits three technical events as part of its operation: $identify (associates a session with your account identifier after login), $feature_flag_called (records that a feature flag was evaluated, so we know which app variant you saw), and $exception (an error occurred). These follow the master analytics switch like everything else.
4.5 Logs and reliability
In plain words: our servers keep short-lived technical logs so the service works and abuse can be stopped, and the app reports crashes so we can fix them. Crash reports include your handle, so we can follow up on a bug you hit.
- Request logs: our appview servers log technical request data (IP address, timestamp, endpoint, technical headers, including the analytics consent headers that drive the pipeline above). Purpose: keeping the service running, debugging, and detecting abuse. Retention: 90 days, then deleted.
- Crash and error reports: when the app or our servers hit an error, a report is captured by PostHog (the same analytics processor described in Section 4.4, via its
$exceptionevent) with technical context, enriched with your user handle so we can correlate a crash with a support conversation or reach out about a bug that affected you. Crash data is stored in the EU alongside our analytics. Retention: 90 days. Error reports follow the analytics master switch where technically separable; server-side error records are part of running the service. - Observability data: aggregate performance metrics (latency, error rates) contain no personal information.
4.6 Moderation
In plain words: when you report something, we keep the report and what we did about it. That record protects you and everyone else, so it outlives the content it concerns.
When you report content or a user, we record: your identity as reporter (never shown to the reported user), the reported content, and the moderation decision and actions taken (the audit trail). We operate a moderation console and an AT Protocol labeler; labels we publish are part of the protocol's public moderation infrastructure. Moderation records are retained for 2 years after resolution, or longer where the law requires it (for example, reports involving child safety), because fair moderation, appeals, and repeat-abuse detection need history. Reporter identity is confidential and disclosed only where the law compels it.
5. What we never collect
In plain words: the shortest section, on purpose. These are commitments, not current coincidences.
- Your date of birth. Age is self-certified with a checkbox; we store the fact of certification only.
- The content of your posts, for analytics. What you write is for the network you publish to, not for our metrics.
- Your precise location. No GPS, no location permissions.
- Your acquisition source. We don't track where you heard about Tempo, and we don't buy or attach advertising identifiers.
- Marketing profiles. No advertising, no sale of personal information, no profiling for ads.
This list is deliberate data minimization under Law 25, not a temporary state of affairs. Removing an item from this list would be a material change to this policy (Section 10).
6. Who else touches your data
In plain words: a short, real list. Our processors, the services you choose to connect, and the open network itself. Nobody on this list buys data from us; nobody ever will.
Processors (they act on our instructions):
| Processor | What | Where |
|---|---|---|
| Hosting provider | Runs our servers (PDS, appview, logs) | Canada |
| PostHog | Analytics processing and crash/error reports (Sections 4.4 and 4.5) | European Union |
| Tolgee | Delivers translated interface strings at runtime; sees technical request data only | EU |
| MusicBrainz | Music metadata lookups made by our servers to resolve shared links; receives the queried music item, not your identity | n/a |
Independent services you choose to use (they act under their own policies): Apple Music and Last.fm when you connect them; Spotify and Shazam when you share from them; Apple (App Store, TestFlight) and Google (Google Play, internal testing) as distributors of the app, which process installation and testing data under their own terms.
The federated network: as Section 3 explains, public content is replicated by AT Protocol participants worldwide. They are neither our processors nor our partners; they are the network you are publishing to.
Everyone else: we disclose personal information only if the law compels us (and we will resist overbroad demands), or in a corporate transaction (merger, acquisition), in which case this policy continues to apply to the transferred data and you will be notified.
Cross-border transfers: your account and content data are hosted in Canada. Analytics and crash reports go to the EU (PostHog). Where data leaves Québec or Canada, we assess the destination's protection as Law 25 requires, and rely on appropriate safeguards for EU data (Section 8.5). If the web version of Tempo ships, it will introduce cookies/localStorage; this policy will be updated with a dedicated disclosure before that happens.
7. How long we keep things
In plain words: one table, no surprises.
| Data | Kept for | Then |
|---|---|---|
| Public content (posts, profile, likes, follows) | Until you delete it or your account | Deleted from our systems; deletion propagated to the network best-effort (Section 3) |
| Email, hashed password, session data | Life of the account | Erased within 30 days of account deletion |
| Account creation / acceptance timestamp | Life of the account | Erased with the account |
| Music service tokens | Until you disconnect the service | Revoked and deleted immediately on disconnect or account deletion |
| Analytics: raw events | 13 months | Only aggregates survive |
| Analytics identified to you | Life of the account | Erased within 30 days of account deletion |
| Consent preferences (iCARE) | Until you change them | Erased on day 0 of account deletion; also wiped if you turn iCARE off (Section 4.4) |
| Server request logs | 90 days | Deleted |
| Crash reports | 90 days | Deleted |
| Moderation records | 2 years after resolution | Deleted, unless law requires longer |
8. Your controls and rights
In plain words: the controls live where the data lives: settings panels you can actually find. The rights below are yours by law; the workflows are how we honour them.
8.1 In-app controls
- Analytics: master switch (via the last farewell during early access), iCARE per-category consent, and the settings panel to revisit any decision (Section 4.4).
- Music services: disconnect any service at any time (Section 4.3).
- Content: delete any post; edit your profile.
- Account: delete your account in settings, or migrate it to another PDS provider (Section 3).
8.2 Access and correction
You may ask what personal information we hold about you, and have inaccurate information corrected. Write to privacy@tempomusic.app; we respond within 30 days (Law 25/PIPEDA timelines).
8.3 Portability and export
Your content's native export is the AT Protocol repository export: a complete, machine-readable copy of your public records, obtainable in-app or by request, and usable at any other provider (that's the point of the protocol). Analytics data identified to you can be exported on request to privacy@tempomusic.app.
8.4 Deletion
Delete your account in settings or by writing to privacy@tempomusic.app. Timeline: consent preferences erased on day 0; content deletion issued immediately (network propagation per Section 3); identified analytics and account data erased within 30 days; short-lived logs age out on their own schedule (Section 7).
8.5 If you are in the European Union
For EU testers and users, La Corporation Tempo Inc. is the data controller. Our legal bases are: contract (running the service you signed up for: account, content, connections you initiate); consent (analytics under iCARE, any future optional features that ask first); and legitimate interest, used narrowly for security, abuse prevention, and service logs (Section 4.5), never as a catch-all for collection we couldn't justify to your face. You additionally have the rights to restriction and objection, and to lodge a complaint with your local supervisory authority. Transfers of EU data to Canada rest on Canada's adequacy decision (for PIPEDA-covered processing); analytics remain in the EU with PostHog.
8.6 Complaints
We'd rather hear it first: privacy@tempomusic.app. You may also complain to the Commission d'accès à l'information du Québec, the Office of the Privacy Commissioner of Canada, or (EU) your local data protection authority.
9. Children and age
In plain words: Tempo is for ages 13 and up, we take your word for it by design, and we collect nothing that would let us second-guess you.
The service requires users to be at least 13 years old (and, where local law sets a higher age for consenting to data processing, that higher age or parental consent; see the Terms of Service). We do not collect birth dates; where an age gate is shown, it is a self-certification checkbox and we store only its acceptance. If we learn an account belongs to a child under 13, we will delete the account and its data. Parents or guardians can reach us at privacy@tempomusic.app.
10. Changes to this policy — and how you'll verifiably know
In plain words: we tell you in the app, we keep a public change log, and our analytics roadmap makes silent changes detectable from outside. You never have to trust that nothing moved; you can check.
When this policy changes materially, we will notify you in the app (the same channel that announces analytics changes) before the change takes effect, with the notice periods Québec consumer law requires where applicable. Every version of this policy is numbered and archived with a change log, so you can see exactly what changed between versions. New analytics categories always arrive switched off and announced (Section 4.4); once the public machine-readable analytics manifest ships, any change to what we collect will be externally verifiable: a constraint on us, by design.
Continued use after the effective date of a revised policy constitutes acknowledgment of the revision; where the law requires fresh consent (for example, a new purpose for existing data), we will ask for it explicitly rather than infer it.
Questions, corrections, or the feeling that something above is vaguer than it should be: privacy@tempomusic.app.