app-aozora-yoro (Messenger) — Privacy Policy

DRAFT — not legal advice; counsel review required.

Governing law: Japan

• Effective date: 2026-07-02
• Last updated: 2026-07-28
• Data controller / operator: AWAI Network, L.L.C., a Delaware limited liability company (Delaware file number 10704996) — the same controller as app-aozora. Gftd Japan 株式会社 is an infrastructure and software supplier, not the controller. Full operator record: legal/company.md.
• Service: app-aozora-yoro (messenger)

This policy explains how yoro Messenger handles personal information. It supplements the app-aozora Privacy Policy, which also applies. Our primary regime is Japan's APPI; where applicable, GDPR (EU/UK) and CCPA/CPRA (California) also apply. yoro Messenger shares the same identity graph and account system as app-aozora.

1. Information we collect

• Identity & account data: your DID, handle, and authentication data, shared with app-aozora.
• Conversation data:
  • Message content — 1:1 direct messages are end-to-end encrypted by default: the client encrypts message content before it ever reaches our servers (Signal-protocol-style X3DH session establishment + Double Ratchet for post-compromise security), and we store ciphertext only for these threads. Group threads use a sender-keys encryption scheme, established lazily on the first message sent in that conversation rather than asserted when the conversation is created. Some group/project threads may instead be explicitly marked as plaintext shared-room conversations, for which we store the message text and embeds directly. (Confirmed from the current, shipped send/receive implementation — this is live behavior, not a design intent.)
  • Conversation metadata — conversation and message identifiers, sender DID, membership/participants, timestamps, content type, reply references, reactions, read receipts, and unread counts. We index this metadata to deliver messages, order threads, and track delivery/read state. This metadata is not encrypted even for end-to-end-encrypted threads — we can see who is talking to whom and when, just not the message content.
• Attachments (blobs): media/records you attach, stored content-addressed (by CID) in a Cloudflare R2 bucket (aozora-pds-blobs), served R2-first with an IPFS-gateway fallback for reads.
• Contact/discovery data: relay-imported accounts, profiles, and follow-graph data used to build your people list and suggestions. Confirmed: we do not import your device/phone contacts — discovery is purely graph-derived.
• HITL/agent-interaction data: decision threads, options presented, and the answers you submit when you use the agent decision inbox.
• Usage & device data: logs, IP address, device/browser info, and notification tokens. Push notifications (Web Push, RFC 8291/8292) carry only a generic body ("You have a new message" / "You have a new group message"), the app name as title, and the conversation ID — never the message content or a preview of it.

2. How and why we use it, and legal bases

For encrypted threads we cannot read message content; our processing is limited to ciphertext storage and metadata.

3. Sharing and subprocessors

• Infrastructure / subprocessors: Cloudflare — Workers (relay/indexer), kotobase/Datomic-style store, D1, and R2 (attachments). Confirmed: Backblaze B2 is not used. [DECISION NEEDED: confirm DPA status with Cloudflare.]
• Conversation participants: message content and receipts are shared with the other members of a conversation.
• Automated agents: decision content and your answers are shared with the agent only in HITL flows you explicitly initiate via the decision inbox. Confirmed from the architecture: the HITL pipeline is a separate, isolated proxy (browser → HITL API → agent-runtime service) that has no code path into your conversations, messages, or contacts — an agent only ever sees the specific decision content it surfaces to you and the answer you give it.
• Legal / safety: authorities where required by law or to protect rights.

We do not sell personal information for money. [DECISION NEEDED: with B2 ruled out, Cloudflare is the sole current infrastructure subprocessor — confirm DPA status and whether a formal subprocessor registry should be linked here instead of enumerated in-line.]

4. International transfers

Infrastructure (Cloudflare, US-headquartered) processes data outside Japan, including the United States. For APPI we provide required cross-border- transfer information; for GDPR we rely on adequacy decisions or Standard Contractual Clauses. [DECISION NEEDED: the specific legal transfer mechanism is a legal determination, not code-derivable — needs counsel input.]

5. Retention

We retain conversation records and metadata for as long as needed to provide the messenger and for legal purposes. When you delete a message, it is tombstoned (removed from your conversation and from reads) rather than physically purged from the underlying transaction log; reactions, receipts, and attachments already attached to that message are not cascade-deleted along with it — a deliberate, documented scope limit. [DECISION NEEDED: confirm whether this tombstone-not-purge behavior needs stronger disclosure, and set concrete retention periods for backups and the underlying log, which are not yet defined.]

6. Security

Encryption in transit; end-to-end encryption for direct messages is implemented and live by default (Signal-protocol-style X3DH + Double Ratchet; confirmed from the current send/receive implementation, not just design intent — see §1). Access controls and secret management protect metadata and infrastructure. No system is perfectly secure. [DECISION NEEDED: a formal security program description and breach-notification process/SLA are organizational commitments, not code-derivable.]

7. Your rights

• APPI (Japan): disclosure, correction, addition/deletion, cessation of use, and cessation of third-party provision, and disclosure of provision records.
• GDPR (EU/UK): access, rectification, erasure, restriction, portability, objection, and withdrawal of consent; complaint to a supervisory authority.
• CCPA/CPRA (California): know, access, delete, correct, and opt out of sale/sharing; non-discrimination.

Note: for end-to-end-encrypted content we may only be able to act on ciphertext and metadata, not plaintext. To exercise rights, contact us (Section 9); we verify identity via your account/DID (method confirmed). [DECISION NEEDED: a concrete response-timeline SLA is a business commitment, not code-derivable.]

8. Children

[DECISION NEEDED: minimum age and children's-data handling — see app-aozora Privacy Policy §10 (same underlying gap: no age gate exists anywhere in account creation today). COPPA and GDPR Art. 8 considerations need counsel input.]

9. Contact and representatives

• Controller: AWAI Network, L.L.C., a Delaware limited liability company (Delaware file number 10704996)
• Privacy contact: hello@gftd.co.jp (a temporary operational address; an AWAI-controlled address will replace it)
• Registered agent and registered office: Legalinc Corporate Services Inc., 131 Continental Dr, Suite 305, Newark, DE 19713, United States — statutory service-of-process address only
• Infrastructure and software supplier (not the controller): Gftd Japan 株式会社, GranTokyo South Tower 11F, 1-9-2 Marunouchi, Chiyoda-ku, Tokyo 100-6611, Japan (Corporate Number 1011101086505)
• APPI applicability: same as app-aozora — the controller is a foreign business directly bound by APPI's extraterritorial application (Art. 171) for personal information of individuals in Japan. See app-aozora Privacy Policy §11 and legal/company.md.
• APPI consultation desk: [DECISION NEEDED: an organizational process/ contact, not code-derivable.]
• EU/UK GDPR representative (Art. 27): 該当なし (not designated). Unchanged by the 2026-07-28 operator change (the controller was outside the EU/UK before and after) and still open.
• DPO: 該当なし (not designated)

10. Changes

We may update this policy and will post the updated version with a new "last updated" date; material changes will be notified through the Service.