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.
- Before you have an account, you can sign up on tempomusic.app to receive an invitation code; we ask only for your email and your preferred language, kept until you unsubscribe (Section 4.7).
- 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, Apple Music, Shazam, Deezer, YouTube or YouTube Music 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, crash reports and short-lived operational copies of our server logs and traces are processed by PostHog in the EU (Sections 4.4, 4.5).
- 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). Where an age gate is shown at signup, it is a self-certification checkbox ("I am at least 13 years old") that conditions submission on-device and nothing about it is stored.
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. For those accounts we also record when your account first connects to Tempo — at the latest, your first connection after this policy took effect. It plays the same role as the account creation timestamp above: the minimal record that the service relationship (and your acceptance of the Terms and this policy) began. It is written once, never shown anywhere, and erased with the rest of your gateway data when your account's data is deleted.
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, Apple Music, Shazam, Deezer, YouTube or YouTube Music 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, Apple Music, Shazam, Deezer, YouTube, YouTube Music, and system share sheets):
- When you share a song or album into Tempo, we receive the shared link. 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 (planned, not shipped). We plan to show you "fun facts" about your own listening and posting, computed locally on your device and never transmitted, that will keep working even when you are fully opted out. A generic observation channel already runs before the consent gate on purpose, so this feature can plug into it when the time comes: insight for you should not require collection by us. This paragraph reserves the design; it does not promise or perform it.
Retention. Raw events are deleted by our analytics processor after 12 months (its plan-level retention); only aggregate statistics survive beyond that. 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 (4 events, consentable, refusable under iCARE)
The publishing funnel: opening the composer, attaching music, and whether publishing succeeds.
| Event | Why we collect it | Properties |
|---|---|---|
composer_abandoned | Measure how many opened composers end in an explicit abandon, closing the publishing funnel. | — |
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, how long publishing takes, and whether the catalogue could complete the record's identity before it was written. | enrichment, error_category, outcome, reason, 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, Apple Music, Shazam, Deezer, YouTube, YouTube Music, 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_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_overrode_native_publish | Count times an external share overrode an in-progress native publish, to measure FAB→share friction. | — |
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 (4 events, consentable, refusable under iCARE)
Coarse engagement actions: opening the feed, liking, replying, and whether the play sheet of a song found every listening link. 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. | — |
release_sheet_links_resolved | Measure how often the play sheet opens on a record that lacks a streaming link, and whether looking the missing link up by ISRC fills it — the signal that decides whether older records get repaired. | had_isrc, outcome, providers_after, providers_before |
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 two technical events as part of its operation: $identify (associates a session with your account identifier after login) and $exception (an error occurred). These follow the master analytics switch like everything else, enforced at two layers: the SDK is toggled into an opt-out state that blocks all captures, and our own event sink filters them independently so nothing slips through if the SDK behaviour ever changes. Feature flag lookups (used for remote configuration) emit no telemetry at all.
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. A short-lived operational copy of the server logs and traces also goes to our analytics processor in the EU, because that is where we debug the service. Crash reports include your handle, so we can follow up on a bug you hit.
- Reverse-proxy request logs: the reverse proxy in front of our servers logs technical request data (IP address, timestamp, path, status, user-agent) so requests can be routed and abuse detected. Kept in Canada; rotated weekly and pruned after 4 rotations (~4 weeks).
- Server-side request logs: our servers (appview, gateway, music catalogue) log technical request data: endpoint, technical headers — including the analytics consent headers that drive the pipeline above — and the analytics identifiers of the request (your analytics distinct id and session id), which let us follow one request across systems; no IP is added at this layer since the reverse-proxy layer above already logs it. A local copy stays in Canada as rotating files (~50 MB × 5 per service), automatically pruned after 60 days. A copy is also shipped to PostHog (EU) — the same processor as our analytics — where we read it to operate and debug the service; PostHog keeps it for 14 days.
- Crash and error reports: when the app or our servers hit an error, a report reaches PostHog. The app captures it through the
$exceptionevent (Section 4.4), enriched with your user handle so we can correlate a crash with a support conversation or reach out about a bug that affected you;$exceptionfollows the master analytics switch, so when you have opted out no crash report leaves your device. Crash reports are ordinary analytics events for our processor and follow the same 12-month deletion as raw events (Section 4.4). Server-side errors travel inside the server logs described just above, as part of running the service (Section 8.5), and follow that pipeline's retention. - Observability data: aggregate performance metrics (latency, error rates) contain no user identifiers. The technical traces our servers emit do carry technical identifiers — your DID (your public account identifier) and the same analytics identifiers as the server logs — so a single request can be followed across systems when debugging; they go to PostHog (EU) through the same operational pipeline as the server logs and expire on the same 14-day schedule.
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.
4.7 Early-access signup form (website)
In plain words: if you sign up on our website to receive an invitation code, we ask for two things: your email and whether you use an iPhone or an Android. We keep them as long as you want to stay on the list, and you unsubscribe with one click.
Our marketing website (tempomusic.app) offers an early-access signup form. When you submit it, we collect exactly:
- your email address, so we can send you an invitation code and short messages about the app you signed up for;
- your preferred locale (English or French), so those emails reach you in your language;
- your device platform (iPhone or Android), so we can plan invitations and builds for the platform you will actually use.
Before submission, your browser runs Cloudflare Turnstile, an anti-bot check that verifies a machine-generated challenge and does not deposit tracking cookies for that purpose; no user profile is built. Once verified, your email, locale and device answer are sent to MailerLite, our email processor (servers in Germany and the Netherlands, European Union), and added to a single "early-access" list.
- Legal basis: your explicit consent, given by submitting the form. For users in the EU (Section 8.5), this is Article 6(1)(a) GDPR consent, for the invitation and app-related updates purpose only.
- Retention: as long as you remain subscribed. Every email includes a one-click unsubscribe link (MailerLite handles it); you may also write to privacy@tempomusic.app.
- What we never do with this list: transfer it to advertising networks, enrich it with third-party data, sell it, or use it for anything other than the invitation and app-related updates you signed up for.
The website itself does not set analytics or advertising cookies. If that changes, this policy will say so with a dedicated disclosure before the change takes effect.
5. What we never collect
In plain words: the shortest section, on purpose. These are commitments, not current coincidences.
- Your date of birth. Where an age gate is shown, it is a self-certification checkbox and nothing about it is stored.
- 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 |
|---|---|---|
| Cloudflare Turnstile | Anti-bot check on the website early-access signup form (Section 4.7); verifies a machine-generated challenge, no tracking cookie | Worldwide edge (Cloudflare) |
| Hosting provider | Runs our servers (PDS, appview, logs) | Canada |
| MailerLite | Delivers the early-access invitation and app-related updates to subscribers (Section 4.7) | European Union (Germany, Netherlands) |
| MusicBrainz | Music metadata lookups made by our servers to resolve shared links; receives the queried music item, not your identity | n/a |
| PostHog | Analytics processing, crash reports, and operational copies of our server logs and traces (Sections 4.4 and 4.5) | European Union |
Independent services you choose to use (they act under their own policies): Apple Music and Last.fm when you connect them; Spotify, Apple Music, Shazam, Deezer and YouTube (including YouTube Music) 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, crash reports, and operational copies of our server logs and traces go to the EU (PostHog). Early-access signup emails go to the EU (MailerLite). 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). Our marketing website (tempomusic.app) is the Next.js site that hosts the pages you are reading and the Section 4.7 signup form; it does not set analytics or advertising cookies today. A web build of the Tempo Music app itself is in development; when it ships it may introduce cookies/localStorage, and 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 |
| First-connection timestamp (external accounts, Section 4.1) | Life of the account | Erased with your gateway data on account deletion |
| Music service tokens | Until you disconnect the service | Revoked and deleted immediately on disconnect or account deletion |
| Analytics: raw events | 12 months | Deleted by our analytics processor; 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) |
| Reverse-proxy request logs (IP, path, status, user-agent) | ~4 weeks | Deleted (weekly rotation, 4 kept) |
| Server-side request logs (endpoint, technical headers, no IP) | Local copy: 60 days · PostHog copy: 14 days | Pruned automatically (local); expires at PostHog |
| Server traces (DID, analytics identifiers) | 14 days (PostHog) | Expire |
| App crash reports (PostHog) | 12 months | Deleted with raw events |
| Moderation records | 2 years after resolution | Deleted, unless law requires longer |
| Early-access signup email + locale + device (Section 4.7) | Until you unsubscribe | Erased on unsubscribe or on written request to privacy@tempomusic.app |
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 by request to privacy@tempomusic.app, and usable at any other provider (that's the point of the protocol). An in-app export is planned; this sentence reserves the mechanism, it does not promise or perform it. Analytics data identified to you can be exported by the same request.
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, crash reports and the operational copies of server logs and traces 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 nothing about it is stored. 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.