Data Processing and Integration Addendum

Version 1.0 · Effective 8 July 2026 · Kudomos (ABN 15 384 058 395)

Forms part of the Privacy Policy and Terms of Service (see Terms §2a — the permission wall).

Schedule A: Authenticated Third-Party Profile Routing Map

1. Purpose and scope

This Schedule sets out how Kudomos ("the Platform") handles external third-party profile links and communication routing. It applies strictly to the scenario where a member ("User A") explicitly authorises the Platform — via an identity handshake (OAuth 2.0 / OpenID Connect) or deliberate manual entry — to store a pointer to their public social profile for the exclusive purpose of displaying a directional link to another authorised member ("User B") behind the credentialed permission wall.

2. Group-duration consent (the 360° rule)

When User A acts on Address, Invite, or Submit within a 360° combination group, any resulting grant — open invitation or a specific member grant — is valid only for the duration of that 360° combination group:

• Every grant is recorded against the specific group and carries a hard expiry equal to the group's lifetime; expired grants are inert at read time (they are filtered out server-side, not merely hidden).
• A grant names a specific counterpart (User B); it never extends to other members, other groups, or future re-formations of similar geometry.
• Blocking a counterpart force-expires every live grant between the two members immediately.
• Renewal requires a new affirmative act by User A in a new group window. Silence never renews.

3. Data mapping matrix (as built)

| Data category | Specific elements | Technical source & method | Processing purpose | Retention & storage |

|---|---|---|---|---|

| Identity pointers (X, Facebook, LinkedIn, Discord, Reddit, Twitch, YouTube, TikTok) | Platform + handle only (e.g. x / jsmith) with a verified flag. No profile URLs, no provider UIDs, no display content. | Standard OAuth 2.0 / OpenID Connect authorization-code flow (PKCE where required) initiated by User A, with minimal scopes (public_profile, openid profile, identify, identity or equivalent). Manual entry is stored unverified. | To display a verified, directional "connect on X" link exclusively to a User B holding a live grant (§2), enabling manual, external peer-to-peer connection. | user_socials row in the member database (D1, OC region), owner-only via the API. Retained for the active account lifetime or until disconnected. |

| Direct contact routing (e.g. WhatsApp/Telegram click-to-chat) | Platform + handle string as entered by User A. | Manual member input. Marked unverified. | To let an authorised User B initiate external contact with User A. | Same store and lifecycle as above. |

| OAuth access tokens | Not retained. | Used once, in-flight, to read the proven handle from the provider. | Ownership verification only. | Never written to any store. |

4. Legal and technical boundaries

4.1 Zero data harvesting and content scraping. The Platform does not fetch, pull, aggregate, read, or cache any content timelines, private messages, media, friend/follower lists, or historical activity from any integrated network. Processing is limited to a single ownership-verification read of the member's own handle at connection time, and thereafter to the handling of the static pointer.

4.2 Native privacy preservation. The Platform does not bypass or alter any privacy control of an external network. When User B follows an authorised link, they leave the Platform; User A's visibility there remains entirely subject to User A's own native privacy configuration on that network.

4.3 Instant revocation. User A retains complete sovereignty over connected profile pointers. Disconnecting a platform in the member dashboard permanently deletes the pointer from the production database synchronously — within sixty (60) seconds at the outside; in practice, in the same request. Account deletion (DELETE MY DATA) purges all pointers in the same operation. Revocation also occurs implicitly when a grant expires with its group (§2) — the pointer stops being served even while stored.

4.4 The permission wall (restatement). No pointer is ever displayed publicly, to search engines, to non-members, or to members without a live grant. See Terms §2a: data behind the permission wall cannot be harvested or accessed without unambiguous, affirmative consent from the individual it concerns.

---

Appendix — Integration setup (operator runbook)

Per-provider setup is three steps; no elevated API approvals are required for the minimal scopes.

1. Developer console registration (per platform — Meta for Developers, LinkedIn Developers, etc.)

- Create the app entry; set the redirect URI to exactly https://horoscorpio.com/api/auth/social/callback (and the hrsc-db.pages.dev equivalent for staging).

- Copy the Client ID (public) and Client Secret (private).

- Select the lowest data-access scopes: Facebook public_profile · LinkedIn openid profile · X users.read tweet.read · Discord identify · Reddit identity · Google/YouTube youtube.readonly · TikTok user.info.basic.

2. Backend configuration — store credentials as Pages encrypted secrets OAUTH_<ID>_CLIENT_ID / OAUTH_<ID>_SECRET (never in code, never client-side). A provider is live the moment its two secrets exist; until then the UI falls back to manual (unverified) entry. The schema (user_socials) and the handshake (/api/auth/social/start → provider → /api/auth/social/callback, HMAC-signed state, 10-minute expiry, PKCE) are already built.

3. Frontend — User A: "Connect <platform>" buttons (built). User B: the gated destination link renders only behind a live grant and always carries rel="noopener noreferrer" with target="_blank" so the external page detaches from the Platform's browsing context.

Not integrated by design: Instagram (Basic Display API retired; Meta business flow only) and Telegram (Login Widget, not OAuth) — manual entry only until a compliant flow is added.