| October 10, 2026 | European outbound calls on Telnyx now have their records stored in GermanyLire la suite de cette entrée- What changed. Outbound calls that Telnyx carries for European workspaces now run on our separate European Telnyx account. That account stores its call records in Germany. This applies to calls placed since October 10, 2026.
- What did not change. No sub-processor was added or removed. Texts, inbound calls, and other regions' calls stay on our main Telnyx account, which stores its records in Canada. So do the records of European outbound calls placed before October 10. This is where Telnyx keeps records at rest, not where it processes a call. Telnyx treats processing location as a preference, not a guarantee.
- The Telnyx entry, the data residency page and our GDPR page now say so.
|
| October 10, 2026 (later the same day) | Sign-in, the number directory, membership and our own subscription records now run in each workspace's own regionLire la suite de cette entrée- What changed. Each region now runs its own sign-in, workspace directory, membership, phone number routing, subscription records, shared operational state and scheduled jobs: Montreal for Canada, Frankfurt for Europe, Singapore for Asia-Pacific and the United States for United States workspaces.
- A frozen earlier copy of the moved sign-in, directory, membership and number routing records is kept in the United States so we can roll back, and in our encrypted backups. For Asia-Pacific that copy is also read: our United States relay checks a dashboard's access against it before passing on live call updates.
- What did not change. No sub-processor was added or removed. Payments (Stripe) and email (Postmark) stay in the United States, as do texts through Telnyx's United States interface and Asia-Pacific's live call updates, which ride a message bus in the United States and are passed on by our relay there. Monitoring stays in the European Union. The Cloudflare edge, our secrets store, push notification delivery and the optional video avatar stay outside the region.
- The Google Cloud and Redis entries, the data residency map, the privacy policy and our GDPR and region pages now say so.
|
| October 9, 2026 | Telnyx now stores its records of our calls and texts in CanadaLire la suite de cette entrée- What changed. Telnyx stores its call, message and conference records for our account in Canada. That covers every region's Telnyx traffic, European and Asia-Pacific workspaces' included, because the setting applies to our whole Telnyx account. Telnyx has confirmed that moving our earlier records to Canada is complete.
- What did not change. No sub-processor was added or removed. This is where Telnyx keeps records at rest, not where it processes a call or a text. Texts on numbers we issue through Telnyx still go through its United States messaging interface, and Telnyx treats processing location as a preference, not a guarantee.
- The Telnyx entry, the data residency page and our GDPR page now say so.
|
| October 8, 2026 | Notice: adding Microsoft to alert District AI for Windows while the app is closedLire la suite de cette entrée- Microsoft Corporation is being added as a sub-processor for the Windows Push Notification Services. It will ring District AI for Windows for an incoming call, and tell it a new message has arrived, while the app is closed.
- This is notice: the change takes effect no sooner than 30 days from this entry, and you can object in that window at legal@distronode.com. Nothing is sent to Microsoft before then.
- It affects only people who use District AI for Windows and turn on its alerts for a closed app: "Ring on this computer" for calls, and a setting of its own for messages. A workspace whose people do neither sends nothing to Microsoft.
- What Microsoft receives: the computer's notification channel address, identifiers for the workspace and the call or message, and the kind of notification. Never the message text, a phone number or a caller's name. The app fetches those afterwards under its own credential.
- Where: Microsoft does not publish where it processes a notification or let a sender choose a region, so these notifications leave every workspace's region, European and Canadian ones included.
- For how long: we switch off Microsoft's offline caching, so a notification it cannot deliver at once is dropped rather than held.
|
| October 3, 2026 | Cloudflare no longer holds any call audioLire la suite de cette entrée- What changed. The Cloudflare entry no longer lists a small archive of call-recording audio from an earlier arrangement ageing out of R2. On October 3 2026 we checked every place call audio could have been kept, in every region and at every carrier, and found none. Calls are still not recorded; a call leaves a call record, a transcript and an AI summary.
- What did not change. No sub-processor was added or removed, and Cloudflare still holds our encrypted database backups.
- The Cloudflare entry, the data residency map, the privacy policy, the terms and the signed DPA (v1.10) now say so.
|
| October 1, 2026 | Canadian, European and Asia-Pacific workspaces' stored telephony, messaging and custom-connector credentials are now encrypted with a key held in their own regionLire la suite de cette entrée- What changed. The telephony, messaging and custom-connector credentials a workspace stores with us are encrypted with a Google Cloud KMS key held in the workspace's region: Montreal (northamerica-northeast1) for Canada, Frankfurt (europe-west3) for Europe and Singapore (asia-southeast1) for Asia-Pacific. Credentials already stored for Canadian and European workspaces were re-encrypted onto their region's key; no Asia-Pacific workspace had any stored.
- What did not change. No sub-processor was added or removed; Google Cloud already provided this key service. United States workspaces keep the global key. A Jira connection is still encrypted with an application key kept in our secret store. That store and push notification delivery stay global for every region, and the other services the data residency map lists still leave each region.
- The Google Cloud entry and the data residency map now say so.
|
| October 1, 2026 (later the same day) | Calls on the numbers we issue Canadian and European workspaces are now answered in their own regionLire la suite de cette entrée- What changed. A call on a number we issue a Canadian workspace through Twilio, United States or Canadian, is now answered in Montreal (Amazon Web Services, ca-central-1), and its live-call event is created there. Twilio has no Canadian edge, so the call still reaches Twilio in the United States and is delivered from its Ashburn edge.
- A call on a United States number we issue a European workspace is now answered in Frankfurt through Twilio's Dublin edge, after crossing United States phone networks, and its event is created there. Asia-Pacific workspaces have worked this way since September 26 2026.
- What did not change. No sub-processor was added or removed. A number on a customer's own carrier account is still answered in the United States, as is a Twilio number held by a United States workspace. Sign-in, the number directory, billing, our secrets store, the Cloudflare edge, email and Twilio's own account data stay outside the region, and Twilio has not confirmed its processing location in writing.
- This replaces the September 10 2026 rule that the carrier alone decides. The Twilio, Google Cloud and Amazon Web Services entries, the signed DPA (v1.8) and our residency, privacy and Sovereign pages now say so.
|
| September 29, 2026 | Mixpanel now also measures our public website, and Google Ads counts demos and checkout startsLire la suite de cette entrée- What changed. Mixpanel, already listed for the signed-in dashboard, now also measures our public pages: pages viewed, clicks on sign-up, checkout and demo links, demos started and forms sent, with the campaign that brought the visit.
- The same safeguards apply. Data stays in the European Union, the SDK loads only after you accept where prior consent is required, it keeps its identifier in localStorage rather than cookies, IP geolocation is off, and nothing is used for advertising.
- On public pages it uses an anonymous identifier and receives no email address and nothing you type into a form. If you later sign in on the same browser, those earlier visits are linked to your account.
- Google Ads now also counts two earlier steps, where your advertising choice allows it: a live demo started after a visit from one of our ads, sent from our servers with only the ad's click identifier, and a checkout started, sent through our Stape gateway in Canada.
- No sub-processor was added or removed. The Mixpanel, Stape and Google entries and the privacy policy now say so.
|
| September 26, 2026 | Asia-Pacific workspaces' calls, speech and AI now run in Singapore, on the providers already listedLire la suite de cette entrée- What changed. For an Asia-Pacific workspace, calls it places and calls on the numbers we issue it are handled on our Singapore machine (Amazon Web Services, ap-southeast-1) and pass through Twilio's Singapore edge. Calls in the dashboard and the District app connect to our Singapore media node. The language model, dashboard AI and knowledge-base embeddings run in Singapore (Google Cloud, asia-southeast1), except the realtime voice engine (United States), which Google does not serve there. New Asia-Pacific workspaces start on Amazon Transcribe and Amazon Polly in Singapore; existing workspaces keep their engine, and other engines keep speech in the United States.
- What did not change. No sub-processor was added or removed. The numbers are United States numbers, so a call crosses United States carriers before it reaches Twilio's Singapore edge, and Twilio has not confirmed its processing location in writing. Live-call events, sign-in, billing, email, shared operational state and texts stay in the United States; monitoring stays in the European Union.
- The Twilio, Google Cloud, Amazon Web Services and Deepgram entries, the LiveKit note, the privacy policy, the data residency map and the terms now say so.
|
| September 23, 2026 | Postmark now delivers only transactional email, because Distronode sends no marketing emailLire la suite de cette entrée- What changed. We have decided not to send marketing email at all. We had built a newsletter, and none was ever sent. It has been retired, and nothing on our website, at checkout or in your account asks you to join a mailing list. The Postmark entry's purpose now reads transactional email delivery, where it read transactional and newsletter email delivery.
- What Postmark still does, unchanged. It delivers the email we send about your account and the service you use: sign-in and verification messages, receipts and invoices, security notices, call reports and usage alerts, and replies to your support requests. The data it receives, where it processes it and its role are the same.
- What this changes for you. No vendor is added or removed, and no category of data or region changes. The privacy policy, the data residency map and the GDPR page say the same thing from today: we send no marketing email, and if that ever changes we will ask for your consent first.
|
| September 23, 2026 (later the same day) | Records, policies and this change log shortened; nothing about our processing changedLire la suite de cette entrée- What changed. We rewrote the sub-processor records, this change log, the Sovereign pages, the data residency map, the privacy policy, and the Terms of Service and Data Processing Agreement summary pages so that no block of text runs past 225 words.
- What did not change. No sub-processor was added or removed, and no processing location, data category or retention period changed.
- The dated history those pages used to narrate stays in this change log. Past entries keep their dates and their links, and each still says what was true on its date, including statements a later entry corrected.
- If you have questions, write to legal@distronode.com.
|
| September 22, 2026 | Clarification: the automated assistant tells a caller the call is transcribed where the workspace's disclosure setting is on, which is the default for Canadian and European workspacesLire la suite de cette entrée- What was imprecise. Our correction of September 21 2026 said the automated assistant tells a caller the call is transcribed, as if every caller heard it. The sentence is spoken where the workspace's disclosure setting is on. That setting is on by default for Canadian and European workspaces and cannot be turned off for a European one. Elsewhere it is on where the business has turned it on.
- What this changes. No vendor, purpose, category of data or region on this page changed. The Google Cloud entry's note on call audio now says where the sentence is spoken.
|
| September 21, 2026 | Correction: Apple is added to this register for the push notifications that ring the District AI iPhone app, which it delivered without an entryLire la suite de cette entrée- Apple Inc. is added as a sub-processor for the Apple Push Notification service, which alerts someone using the District AI app on iPhone to an arriving call or a new message. This register named the Android half, Firebase Cloud Messaging, inside the Google Cloud entry, but not Apple; nothing about how notifications work changed, and the omission was ours.
- What Apple receives: the device's push token, identifiers for the workspace and the call or message, and the kind of notification. Never the message text, a phone number or a caller's name. The words on the lock screen come from the app, which fetches the call or message afterwards under its own credential.
- Where: Apple does not publish where it processes a notification or let a sender pick a region, so a notification to an iPhone leaves the workspace's region for every workspace, European and Canadian ones included. Our September 10 2026 entry already listed mobile push delivery among the things that leave Canada; this names who carries the iPhone half.
- Only a workspace whose people use the iPhone app, and allow it to send notifications, sends anything to Apple. No other entry changed.
|
| September 21, 2026 (later the same day) | Correction: this register described call-recording storage no call has ever used, and personal data we do not holdLire la suite de cette entrée- The Google Cloud entry said each workspace's call recordings were stored in a bucket in its own region, naming four, and that a live-call event carries the recording link; the Cloudflare entry said new recordings went to regional Google Cloud Storage. The buckets hold no call audio.
- No call has ever been recorded: a call leaves a call record, a transcript and an AI summary. Neither the media plane nor the carrier is set to record, and the assistant's opening sentence has always said 'transcribed', not 'recorded'.
- The storage was provisioned ahead of a recording feature, and the register described the provisioning, not the behaviour. Our product pages have described calls this way since September 8 2026; this register lagged.
- Call handling does not change, but we do not hold a category of personal data this register said we did. Any future recording feature will be disclosed here before any call is captured.
- The Google Cloud entry now says the buckets hold number registration documents, and its event description names only the transcript and summary. The Cloudflare entry now names only its legacy archived audio, which is real and aging out. The privacy policy, data-residency map and terms now match; earlier entries stay as published.
|
| September 10, 2026 | Calls on Telnyx-issued Canadian numbers now carried in Montreal; new Canadian workspaces start on a Montreal voice engineLire la suite de cette entrée- Canadian workspaces' outbound calls and inbound calls on our Telnyx-issued Canadian numbers now run on our Montreal machine (Amazon Web Services), not the United States. Telnyx treats its processing location as a preference it endeavours to honour, not a contractual guarantee.
- The carrier decides: calls on Twilio-issued numbers, Canadian or not, still reach us in the United States. New Canadian numbers we issue are Telnyx-issued; existing Twilio numbers and those on your own Twilio account are unchanged.
- Emergency calling is not enabled on any number we issue; none can reach 911.
- For Canadian workspaces the language model now runs in Montreal (Google Cloud) on every engine but realtime (United States); new ones start on an engine with speech in Montreal (Amazon Transcribe and Polly). Existing workspaces keep their engine; other engines keep speech in the United States.
- Dashboard AI moved from the United States to Montreal for Canadian workspaces (EU for European ones).
- Still outside Canada, by decision: sign-in, number directory, billing, shared operational state and account and newsletter email (United States); four-region scheduled jobs (often United States); Cloudflare's global edge; error diagnostics (Germany), telemetry and logs (EU); credential encryption and our secrets (Google global); payments, video avatar, mobile push; and texts on Canadian Telnyx numbers.
|
| September 10, 2026 (later the same day) | Live-call events for Canadian workspaces are now carried and stored in Montreal instead of the United StatesLire la suite de cette entrée- For a Canadian workspace, the events that update your dashboard and inbox live during and after a call now pass through a message bus in Montreal (Google Cloud Pub/Sub) instead of the United States, and the service that pushes them to your browser runs on our Montreal machine. No sub-processor was added or removed.
- A call-start event carries the caller's name and the phone numbers on the call; a call-end event carries the transcript, the AI summary and the link to the recording. Call audio is never sent. Only telephone-network calls produce these events, not browser meetings or video calls.
- Where an event is created still follows the carrier. Calls your workspace places, and calls on Canadian numbers we issue through Telnyx, run in Montreal, so their events are written there. A call on a Twilio-issued number, Canadian or United States, is answered in the United States, so its event is written there, then carried to Montreal and stored.
- The Google Cloud entry now names three message buses and which workspaces use each. The Redis entry now describes six databases rather than five, because a new Montreal database holds our Canadian origin's rate-limit counters. The data residency map, terms, privacy policy and Canadian region page match.
|
| September 10, 2026 (corrections, that evening) | Correction: the realtime voice engine's reasoning is not in Montreal, plus three other Canada correctionsLire la suite de cette entrée- This morning's entry said, in eleven places, that a Canadian workspace's language model runs in Montreal on every voice engine; the realtime voice engine is the exception.
- Google does not serve its model from Montreal, so a Canadian workspace choosing it reasons in the United States (us-east4), as the engine picker says. Every surface carrying the sentence, the Google Cloud entry included, now names the exception.
- That entry also said the Canadian signalling bus carried no telephone trunk configuration; it has carried it since September 10 2026, when that node gained telephone equipment, like the United States and European buses.
- The residency map's table omitted the Montreal rate-limit counter database (Amazon Web Services, ca-central-1) added September 10; it and the privacy policy now count three shared databases.
- The Canada roll-up now also names workspace membership, held in the United States with sign-in; database backups, encrypted in Montreal with the key kept back, in a Cloudflare bucket whose location Cloudflare chooses; optional lead enrichment via United States data providers, only results returning to Montreal; and the realtime engine's reasoning. It counts eighteen rows, not fifteen.
- The Telnyx and Amazon Web Services entries now separate outbound, every Canadian workspace's calls, from inbound, only Telnyx-issued numbers. No processing location changed this evening.
|
| September 10, 2026 (fourth entry, that night) | Cartesia added as an optional voice engine, processed in the United States for every workspace that chooses itLire la suite de cette entrée- A workspace can now choose Cartesia's Sonic model as its assistant's voice, alongside the other voice engines; nothing changes for a workspace that does not. Cartesia receives the assistant's text and returns the synthesized audio; the caller's audio stays with the speech-recognition engine already listed.
- Speech synthesis on this engine runs in the United States for every workspace, including European and Canadian ones. Cartesia offers European, British, Indian and Australian endpoints only on its Enterprise tier, which we do not hold, and publishes no Canadian one. The engine picker labels the leg that leaves the region before the choice is made, and a European workspace needing every leg in region keeps its starting engine.
- Cartesia admitted Distronode to its Startups programme in September 2026, moving the account onto a plan with a commercial licence. Until then the engine existed only for our own evaluation and was kept out of this register, because a row here is a claim that customer speech reaches the vendor, and it did not.
- Added: a Cartesia row in the speech group, and Cartesia in the privacy policy's list of optional voice engines, in both locales. No other sub-processor was added or removed, and no existing workspace's engine changed.
|
| September 3, 2026 | Correction: not every customer number is a United States number; workspaces can hold European and Canadian numbersLire la suite de cette entrée- Workspaces can hold Canadian and European numbers, not just United States ones: Estonia needs no paperwork from you (we hold its registration), and other European countries open once your own registration is approved. No sub-processor was added or removed, no data changed hands, and no existing number changed.
- A European number's calls reach our Frankfurt equipment through Twilio's Dublin edge and are answered, hosted and transcribed in Europe. A Canadian number's calls reach us in the United States and run on our United States media node in both directions.
- Our Twilio entry said phone calls were United States for 'every customer number today' and that European numbers were 'not yet generally available' to customer workspaces. Both were true when written and stopped being true today.
- Where else the same sentence lived, all corrected the same day: the data residency map, our terms, privacy policy and about page, and our Google Cloud and Amazon Web Services entries carried some form of 'every customer number today'. Our August 19 and 28 entries stay as published.
- Unchanged: we make no claim about Twilio's processing past our handoff; Twilio has not confirmed its processing location in writing. Registration documents you submit are still held by Twilio's regulatory-compliance service in the United States.
|
| August 31, 2026 | Sinch entry corrected against the account itself: SMS and voice only, and a 180-day retention of message content at Sinch is now disclosedLire la suite de cette entrée- The Sinch entry said Sinch carried WhatsApp messages for us. Our Sinch account has no WhatsApp channel configured, so no WhatsApp message has ever passed through Sinch; the entry now lists SMS and voice, which is what the account actually does. This is a correction to a description, not a change in what happens to any data.
- Added, because it was true and unstated: Sinch's messaging service keeps its own copy of message content for 180 days after delivery, its default retention, and deletes it afterwards. That copy exists in Sinch's United States region alongside the message routing the entry already disclosed. Our own retention of message content is governed by the privacy policy and is unchanged.
- Both facts were read from the account configuration directly rather than from our own description of it, which is the standard every entry on this page is held to.
|
| August 29, 2026 | Number registration in some countries may mean we hold government identity documents for the first timeLire la suite de cette entrée- The dashboard now guides a workspace through the documents some countries' telephone regulators require before a number there can be held. Nothing changes unless you start a registration; United States and Canadian numbers need none.
- They are a business registry extract, a proof of address and, for a number registered to an individual, a government identity document such as a passport or national identity card: the most sensitive data we can now hold, above call audio. We receive one only when a person chooses individual registration and uploads it, never for company registrations accepted with business documents, and for no other purpose.
- Our copy sits in a dedicated bucket in the workspace's region, like recorded call audio, separate from recordings, readable only via short-lived dashboard links. Only on submission do the documents go to the carrier, Twilio, whose regulatory-compliance service runs in the United States.
- Documents are deleted thirty days after the number is released or registration withdrawn, or immediately with the workspace or account.
- Declaring a company as an individual, or the reverse, would be a false declaration to the regulator, so the flow requires the declared type's documents.
- The Twilio and Google Cloud entries, residency map, privacy policy and Data Processing Agreement now cover these documents.
|
| August 28, 2026 | Outbound Twilio calls for European workspaces now connect through Dublin; our first European number went live, answered in EuropeLire la suite de cette entrée- Twilio calls our assistant places for European workspaces now go from Frankfurt to Twilio's Dublin edge, encrypted, instead of its United States edge. Telnyx calls are unchanged, still handed over in Frankfurt.
- Incoming calls now split by the number's country; this entry, amended the same day, first said they were unchanged and that every number we hold was a United States number. A call on a United States number, every customer number today, is still received, hosted and transcribed in the United States. Late on August 28 our first European number went live, in Estonia: its calls reach Frankfurt through Twilio's Dublin edge and are answered, hosted and transcribed in Europe. European numbers are not yet generally available to customer workspaces.
- Our claim stops at the handoff, both ways: our live-call measurements show Twilio handling the media in Ireland there, but Twilio has not confirmed its processing location in writing, so our internal register records it as unconfirmed. The Twilio entry (region chip now US / EU handoff, like Telnyx), data residency map and platform page describe the split.
- We do not use Twilio's documented per-call Ireland region setting: in testing it broke the connection rather than moving it. Nothing changed for Sinch.
|
| August 19, 2026 | Canadian in-browser call media now processed in Montreal; telephone calls are NOT coveredLire la suite de cette entrée- A Canadian workspace's in-browser calls now have their live audio processed in Montreal on Amazon Web Services (ca-central-1), alongside the Canadian website and database, rather than by Google Cloud in the United States (us-east4).
- This includes the relay for networks blocking direct connections; the audio is not stored. The node has its own Montreal signalling bus (Redis Cloud, ca-central-1) and assistant, to prevent a Canadian call being served from a United States machine while its settings say Montreal.
- Telephone calls are NOT covered. Every number we hold is a United States number, so Canadian workspaces' telephone calls, in both directions, reach us and have their media hosted in the United States. The Montreal machine has no telephone equipment; unlike Europe's August 18 change, no outbound telephone calls moved.
- Speech-to-text, the language model and speech synthesis still run in the United States; none of our providers offers a Canadian region, so a Canadian call is not processed end to end in Canada.
- Canadian call recordings were already stored in Montreal by Google Cloud (northamerica-northeast1); that is unchanged.
- The Amazon Web Services entry now discloses this, the Redis entry lists five databases, and the Google Cloud entry no longer claims real-time call media everywhere outside Europe; the residency map matches.
|
| August 18, 2026 | Calls we place for European workspaces now start in Frankfurt; incoming calls still reach us in the United StatesLire la suite de cette entrée- When our assistant places a call for a European workspace, everything on our side now runs in Frankfurt: the call room, the assistant, speech recognition and synthesis, the language model, and the equipment connecting to the phone network. Until today all of it ran in the United States.
- Our Frankfurt equipment hands the call to Telnyx at its Frankfurt site. Past that we neither control nor claim the path, because Telnyx describes its processing location as a preference it endeavours to honour, not a contractual guarantee.
- Inbound calls are unchanged: they still reach us in the United States and are hosted and transcribed there, so a European workspace has calls in both places depending on direction.
- We hold no European telephone number yet: buying one requires a legal establishment in Europe, which is in progress.
- The Telnyx entry, privacy policy and data residency map now describe the split, and Telnyx's region chip reads US / EU handoff. Our internal register records Telnyx's European processing as unconfirmed, because a preference is not a commitment.
- The live dashboard event for a European workspace's outbound call is now created in Frankfurt too; an inbound call's is still created in the United States, as our August 17 entry says.
|
| August 18, 2026 (later the same day) | Our error tracking moved from the United States to Germany, for every regionLire la suite de cette entrée- Sentry, the service that tells us when something breaks, now holds our error diagnostics in its German region instead of its United States one. This covers our website and dashboard, our voice assistant, the service behind the live call dashboard, and our internal reporting tools.
- The data is unchanged: diagnostic reports produced when something goes wrong, which may include IP addresses, user identifiers and, from a browser, the page you were on. It is not call audio, transcripts, messages or contact records.
- For European workspaces this removes a transfer out of your region. For Canadian, United States and Asia-Pacific workspaces it is a change of destination, from the United States to Germany, not a removal: one provider region serves all four of our regions, so this data does not stay in your region unless your region is Europe.
- One caveat, for browsers only. A page already loaded from our site carries the older reporting address, so until a visitor's cached copy expires, an error from that page can still be reported to the United States. Everything on our own machines switched over at once.
- The Sentry entry now reads Germany, and the data residency map has been updated to match.
|
| August 17, 2026 | Correction: our speech engines already used European endpoints for European workspaces; live call events cross to the United StatesLire la suite de cette entrée- The Deepgram and AssemblyAI entries said United States only, contradicting our August 16 entry: a European workspace's speech-to-text and Deepgram speech synthesis already ran on their European endpoints (api.eu.deepgram.com, streaming.eu.assemblyai.com). Both entries now say so; where audio goes did not change.
- Both vendors still process Canadian and Asia-Pacific workspaces in the United States, as neither publishes a Canadian or Singapore endpoint.
- New disclosure: during a call arriving over the phone network, and when it ends, we send an event describing it to an internal message bus (Google Cloud Pub/Sub) in the United States, for every region including Europe, so the live dashboard can show it. In-browser meetings and video calls produce none.
- Events carry the caller's name and the call's phone numbers at the start and, at the end, the transcript, AI summary and recording link. Call audio is not sent.
- A European workspace's in-browser audio is processed in Frankfurt and its speech-to-text in the EU, but the description of a phone-network call still crosses to the United States. We intend to remove this hop for European workspaces.
- The Google Cloud entry now names the bus, what it carries and its United States location for every region; the residency map matches.
|
| August 17, 2026 (later the same day) | Operational cache disclosed, support desk realm is Canada, backups span two R2 jurisdictionsLire la suite de cette entrée- Our Redis entry described one United States database; there are four, one touched on every request in every region, Europe included.
- The fleet-wide one (us-east4) holds rate limits, short-lived caches, webhook idempotency claims and the scheduled-job lock, and serves our Asia-Pacific origin, which lacks its own counter database. Frankfurt's holds only European-origin rate-limit counters. Two are signalling buses for our United States and European media nodes: live-call room and participant state, no audio.
- Keys hold counters and short-lived values tied to identifiers such as an account, workspace, call or IP address; emails, phone numbers and IP addresses in key names are replaced by one-way keyed hashes.
- Our support desk's hosting realm is now confirmed as Canada. One Atlassian site serves all regions, so European, United States and Asia-Pacific workspaces' support requests leave their region for Canada, which the European Commission recognises as adequate for commercial organisations' personal data.
- Our backups, described only as held with Cloudflare, sit in two R2 jurisdictions: European ones in a European-jurisdiction bucket, staying in the EU; United States, Canadian and Asia-Pacific ones in one default-jurisdiction bucket, separated only by key prefix. Each is encrypted in-region before upload, its key held apart from Cloudflare. We intend to move Canadian and Asia-Pacific backups into their own jurisdictions.
|
| August 17, 2026 (later still) | European workspaces' live call events now ride a European message bus, stored in Frankfurt and consumed in EuropeLire la suite de cette entrée- As our first August 17 entry committed, a European workspace's live call events now go to a Google Cloud Pub/Sub bus in Frankfurt (europe-west3) instead of the United States one, pinned so messages are stored there, and are consumed by a dashboard service on our Frankfurt machine.
- The events are still created in the United States, where our carriers terminate phone calls and the software that turns calls into events runs. So a European call's description is written in the United States, then carried and stored in Europe.
- Inbox routing events, pushed when a message arrives or goes out, use the same bus and are created by whichever origin served the request: in Europe when our European origin answered, in the United States when our geographic router sent it there.
- Unchanged: the shared operational database from our second August 17 entry is still one United States database that every region touches on every request. Canadian and Asia-Pacific call events stay on the United States bus: neither region has a dashboard service to read a regional one, and an unread bus would stop their dashboards updating.
- The Google Cloud entry now names both buses and which workspaces use each; the privacy policy and data residency map agree.
|
| August 16, 2026 | European in-browser call media now processed in Frankfurt; telephone call media still in the United StatesLire la suite de cette entrée- European workspaces' in-browser calls now have their live audio processed in Frankfurt, on Amazon Web Services, on the machine that already runs the European website and database. Previously all call media for every region was processed by Google Cloud in the United States.
- This covers browser calls made and received, including the relay used when a participant's network blocks a direct connection. The audio is processed in Frankfurt, not stored there.
- Telephone calls are not covered: their media is still processed in the United States, including for European workspaces, because our carriers terminate calls in North America. Moving that requires a European carrier, which we are pursuing.
- The Amazon Web Services entry now discloses call audio for European workspaces, and the Google Cloud entry says it still handles telephone call media for every region.
- Correction in our own favour: this page said Google Cloud held call-recording storage in the United States, without noting that recordings are stored per region. A European workspace's call recordings are written to a bucket in Frankfurt, as they have been since regional recording storage shipped.
- Speech-to-text, the live-call language model and speech synthesis for European workspaces were already processed in the EU and are unchanged.
|
| August 15, 2026 | Correction: Amazon Web Services hosts three regions and was unlisted; Linode and Civo removed; Atlassian and Zernio addedLire la suite de cette entrée- Amazon Web Services now hosts the website, dashboard and workspace database for Asia-Pacific (from 2026-08-13), Canada and Europe (from 2026-08-14): Singapore, Montreal and Frankfurt.
- We moved without the 30 days' notice our Data Processing Agreement promises, and this page was wrong for one to two days. Objections: legal@distronode.com.
- Akamai / Linode (Asia-Pacific) and Civo (Europe) are removed: their machines were destroyed and neither holds anything of ours, so our 2026-08-02 statement that a European provider holds the European database no longer holds.
- The Google Cloud entry no longer lists the Canadian database, Asia-Pacific storage or a Civo-hosted European database.
- Atlassian is added: since 2026-08-15 it runs our support desk, receiving your name, email, requests, our replies and opt-in knowledge-base questions. One desk serves all four regions, the one place data leaves your region; its realm will be published.
- Zernio is added: X and Reddit are published through this relay, not directly as our 2026-08-03 entry said. No customer personal data was involved.
- Three descriptions are corrected here and in the Data Processing Agreement: databases are reachable only by our servers (not 'no public endpoint'); each hosting provider encrypts storage (not Google Cloud's key service); the backup key sits apart from the backup host (not 'outside the cloud').
|
| August 9, 2026 | Grafana Cloud removed; New Relic added for infrastructure monitoring, held in the EULire la suite de cette entrée- Grafana Cloud has been removed as a sub-processor and our account there deleted. New Relic replaces it, on a European Union region account, so the operational telemetry it holds for us moves from Canada, where Grafana Cloud held it, to the EU.
- Its purpose is unchanged: watching whether our servers, databases and websites are up and performing, and alerting us when they are not. It is infrastructure monitoring, not analytics, and is not used for advertising.
- We send operational telemetry from our machines and containers (resource usage, request and error counts, uptime probe results) and logs from our own infrastructure: container logs from our application servers and system logs from the host machines, including the database service, the SSH service and the container runtime.
- We do not send call audio, transcripts, message content or contact records. Application logs are scoped to operational diagnostics; a log line may contain an account, workspace or request identifier and an IP address, which our error-tracking sub-processor already receives.
- This records a change already made, not advance notice. Questions or objections: legal@distronode.com.
|
| August 7, 2026 | Notice: adding Mixpanel for product analytics, held in the EULire la suite de cette entrée- Mixpanel, Inc. is being added as a sub-processor for product analytics, on a project with European data residency (api-eu.mixpanel.com), so the data it holds for us stays in the EU.
- This is notice: the change takes effect no sooner than 30 days from this entry, and you can object in that window at legal@distronode.com.
- It measures how the signed-in District dashboard is used. It does not run on our marketing pages and is never used for advertising.
- In your browser: a consent-gated SDK that, where prior consent is required, loads only after you accept; withdraw any time through Cookie preferences in the site footer. It sets no cookies and keeps its identifiers in localStorage.
- From our servers: lifecycle events when an account or workspace is created, a subscription is purchased, a workflow run completes or a call is handled. Browser consent cannot govern this service telemetry: it involves no cookies and nothing in your browser.
- We send usage events keyed to a one-way SHA-256 hashed account identifier, plus the account email and the workspace identifier, region and plan tier; never call audio, transcripts, message content, contact records, phone numbers or IP addresses. IP geolocation is off.
- On account deletion, we forward a deletion request to Mixpanel's data-deletion API; it completes within 30 days.
|
| August 3, 2026 | Bluesky added; Postiz removed as social publishing moves in-houseLire la suite de cette entrée- Added Bluesky Social, PBC as a sub-processor for our own marketing. We are moving our social media publishing off a single scheduling intermediary and onto each platform's own interface, one platform at a time; Bluesky is the first to move, and our Bluesky posts now go to Bluesky directly rather than being relayed.
- Earlier in the day this entry recorded Postiz as still listed and still relaying every other platform, with both relationships genuinely existing at that point. We are leaving that record as written rather than rewriting it after the fact.
- Later the same day, Postiz was removed as a sub-processor. The account was closed and its access ended, and the code that sent anything to it has been deleted, so it no longer relays any platform for us.
- Publishing now goes to each platform's own interface directly. Each platform is listed here on the day it begins receiving our posts, and Bluesky remains the only one listed so far.
- As with every entry in this section, this concerns Distronode's own marketing content and no customer personal data — it never did.
|
| August 2, 2026 | Canadian and European workspace databases moved; LinkedIn added for ad measurementLire la suite de cette entrée- The Canadian workspace database moved from Google Cloud SQL onto Google Cloud compute we operate in Montreal. It, its encrypted backups and point-in-time recovery archive remain there with Google Cloud; no customer data changed hands or crossed a border.
- The retired Akamai / Linode Toronto cluster was decommissioned, ending Akamai / Linode's processing of Canadian data.
- The European workspace database moved from Google Cloud SQL to Civo compute, both in Frankfurt; Google no longer holds European workspace storage. Nightly encrypted backups now run in Frankfurt without first going to the United States, and point-in-time recovery uses encrypted write-ahead logs.
- European data does not stay exclusively in Europe: Google Cloud still processes European live call media in the United States (us-east4), the shared operational cache is one United States instance, and off-site encrypted backups remain with Cloudflare.
- LinkedIn was added to measure our own LinkedIn advertising via its Insight Tag (website events in your browser) and Conversions API (conversion events from our servers). Both are consent-gated; where prior consent is required, nothing loads until you choose.
- We send website and conversion events, SHA-256 hashed email addresses and LinkedIn's first-party advertising cookie identifier; never plaintext emails, IP addresses, mobile advertising identifiers, call audio, transcripts or customer records. This measures our marketing, not your product use.
|
| August 1, 2026 | Full audit of every claim on this page: vendors added, omissions and errors correctedLire la suite de cette entrée- Added Inworld (speech), Tavus (video avatars), SerpAPI (enrichment search) and Stape (server-side analytics gateway); retired the legacy Clearbit enrichment fallback. Clarified that person-level enrichment returns professional contact details and that the EU live-call language model runs in the EU.
- Added two sub-processors in use but never listed: Redis Ltd. (managed Redis for call signaling and short-lived operational state) and Google Analytics & Ads (consent-gated server-side conversion measurement).
- Corrected four descriptions: Twilio lookup (caller ID and line type; no spam screening), Sinch (SMS, WhatsApp and voice; no MMS), Telnyx (first-party carrier; adds MMS) and Grafana Cloud's region (Canada, not the EU). Newly disclosed: legacy call-recording audio aging out of Cloudflare R2, and phone numbers and contact names sent to enrichment providers as lookup keys.
- Correction, and an apology: this page, including a clarification earlier today, said Civo handled European call media from a Frankfurt media node. None exists or existed: all live call media is processed by Google Cloud in the United States, and Civo hosts only the European website and dashboard origin. The Redis entry repeated the error and now names the United States media node.
- The Canadian web tier moved from Akamai / Linode in Toronto to Google Cloud in Montreal, joining the Canadian database. Canadian data residency is unchanged.
|
| July 23, 2026 | Register first publishedLire la suite de cette entrée |
