Invited test · Use fictional information only
Where your entries are stored.
Private entries are saved on your phone first, then use your own iCloud. Posted shared entries are stored in Daytuck’s shared cloud. Saving on your phone, completing sync, and posting for your partner are three separate actions.
Private entries
Saved on your device first, then synced to your own iCloud when it is available.
Shared entries
After you choose to post, current members of the shared journal can view them online.
Personal backups
You create and keep the file. It is not currently password-encrypted.
What content we handle
- Your private content
- Private journals, entry text, selected photo originals and thumbnails, Live Photo motion, and private drafts are used for saving, organizing, and looking back. The current private journal flow does not also upload this content to Daytuck’s shared cloud.
- Your own shared drafts
- Text, photos, and the state of unsubmitted drafts or submissions awaiting verification are saved on your device first and can be backed up privately through your own iCloud. Entering a shared journal or making a backup does not automatically make a draft visible to members. If you see “Check post status”, the original submission may already have been posted. Check it first rather than creating a duplicate post.
- Shared content you choose to post
- Text, originals, thumbnails, and Live Photo motion in shared entries are stored in Daytuck’s shared cloud for access by current members, editing by the author, Recently Deleted, and restoration.
- Account and collaboration information
- Account identifiers, information used to verify sign-in credentials, invitations, member roles, entry versions, and necessary operation results are used for authentication, access control, and checking submissions. Your personal recovery code is a sensitive credential. Do not give it to a partner or include it in feedback.
- Feedback you choose to send
- The version details, reproduction steps, error text, and redacted screenshots you send are used to address the problem. Please do not send recovery codes, passwords, identity documents, photo originals, or full backup files.
This website has no feedback form, third-party analytics SDK, or external fonts. Basic network requests needed to access the website and app services still reach the relevant servers. Actual log fields, retention, and access must be confirmed as external deployment proceeds. This page does not mean that access records are never created.
When iCloud is full, or you are preparing to change phones
Private entries, originals, Live Photos, private drafts, and your own unposted shared drafts use your personal iCloud for sync. When iCloud is off, storage is full, the network is interrupted, or sync is incomplete, content remains on this device. A local save does not mean a cloud backup is complete.
Keep your local content and create a full personal backup first if needed. When iCloud and the network are available, sync again and check the full sync status in the app. This initial version keeps originals on your device and does not automatically free that space by removing them.
Retrieval on a new phone requires the same iCloud account, the same Daytuck account, and the same designated service environment. The same Apple account or display name does not replace signing in to Daytuck. Local content that has neither uploaded nor been backed up cannot be recovered just by signing in. Check sync or your backup before uninstalling.
Personal iCloud is provided by Apple. The limited test service for Daytuck’s shared cloud is hosted in Tencent Cloud’s Shanghai region, with independent backups in Tencent Cloud’s Guangzhou region. Future deployments and processing for other regions need separate explanation. The new test build and earlier development builds use different content environments. Earlier content will not migrate automatically; continuity needs separate validation.
Who can see shared content
Sharing currently supports two people. Before joining, you are told that you will be able to see the shared journal’s existing content. After joining, you can also see entries posted before you joined. Your private journals are not shared as a result. You can edit only entries you posted yourself.
Posting shared photos preserves the originals. Originals and Live Photos may contain metadata such as when and where they were taken. Members who obtain the originals may also obtain that information. Share only content you have the right to use.
After leaving a shared journal, you lose access, while posted content remains in it. The current owner must transfer ownership before leaving. Your own unposted drafts remain, but this does not mean you can still post to a journal you have left. Copies that members have already saved to Photos, Files, or other devices cannot be recalled remotely.
Importing a photo saves a separate file copy for the entry. There is no promise of deduplication with the system Photos library. Please do not delete your Photos originals just because an upload has completed.
Reporting shared content (test candidate)
To report another member or their shared entry, choose a reason and review the preview. Entry text and photos are excluded by default. Only text you select and one static photo preview are included as evidence. We do not automatically collect private entries, other people's drafts, whole journals, photo originals or Live Photo motion. A report does not automatically remove content or change membership.
Evidence is used for human review and retained for at most 90 days from submission or 30 days after closure, whichever is earlier. Related reports are removed when either the reporter or reported person completes account deletion. Restoring an older backup also requires checking the current cleanup state. Historical backups expire under their retention policy; this does not promise immediate erasure of every historical copy. This candidate is being checked with isolated fictional information. Scheduled cleanup and operational deployment still need verification.
If submission status is uncertain, check the original request in “Me → My Reports”. Not finding a receipt does not confirm failure, so do not resubmit the same issue. No initial response deadline is promised yet.
Blocking relationships and exit results (test candidate)
After confirmation, the shared service stores the initiating and target account identifiers, the original affected journal names and role snapshots, the original request ID, and each exit's status. These support invitation restrictions, checking failed or uncertain results, and restoring current access restrictions. This does not automatically collect entry text, private iCloud content, photo originals, or other people's drafts. The in-app blocked list is available only to its initiator.
Unblocking does not restore membership or cancel an exit that has taken effect. Request records used for reconciliation are separate from an active block and are removed when either related account is deleted. The retention period still needs to be decided and implemented before external testing; automatic cleanup is not claimed. This candidate is not publicly available.
What signing out, deleting, and deleting your account mean
- Sign out
- Entries and drafts remain on this device. Use your original personal recovery code to sign in again. Signing out does not mean sync is complete or your account is deleted.
- Move to Recently Deleted
- You can restore an entry within 30 days from the corresponding Recently Deleted area. Manage private content in “Me”. Manage your own shared content in its shared journal.
- Permanently delete an entry
- This cannot be undone in the app. If deleting a shared entry leaves a safety confirmation pending, the action may already have taken effect. Check the original item rather than starting repeated deletion requests.
- Delete your account
- Go to “Me → Delete Account”, verify your original personal recovery code, and confirm again. Once complete, your account and your online content, including Recently Deleted, are removed, and the original recovery code and sign-in become invalid. Content posted by other people in shared journals remains.
Current cleanup gap: The test candidate checks cleanup in private iCloud, the shared cloud, and this device before reporting completion. If a step fails, syncing and posting pause while local data and retry credentials are kept. Live cloud deletion, cross-device behavior, and independent backup handling are still being verified. Backups follow their retention period; holders must manage offline copies on other devices and exported files. Use fictional information only at this stage.
Files you keep and operational backups
A full personal backup file
A .daytuck file made in “Me → Backup & Restore” contains private journals, private entries, private drafts, originals and Live Photo motion, plus your own shared drafts, including submissions awaiting verification. The original submission may already be visible to members and should be checked first. The file does not contain posted shared entries. It is not a backup of a whole shared journal, and it does not restore membership permissions or post automatically.
The file is not currently password-encrypted. Store it somewhere trusted. Import checks the file before merging: identical content in the same account is skipped; a version conflict stops the entire import without overwriting existing content. Older exports can only be inspected and cannot serve as new full restore files.
Operational backups of Daytuck’s shared cloud
The limited test environment has scheduled independent encrypted backups, and retrieval of fictional information has been checked in isolation. These backups do not cover private content that has not uploaded to personal iCloud, and they cannot guarantee recovery of all content from any given moment.
Independent protection of the latest deletion and departure records, formal retention and expiry, and a full manual recovery process are still being verified. An older backup must not reopen confirmed permanently deleted shared content or former members’ access. A recovery database is not opened for access without the evidence needed to check it. We do not promise zero loss, automatic failover, or a fixed recovery time. A planned retention period does not mean all historical copies have already been cleared automatically.
Earlier people, chat, and AI content
New entries do not depend on AI. Writing an entry does not automatically send content to a model or read the system location or calendar. Earlier people, chats, memories, and summaries are kept by account and can be viewed, exported, or deleted from the historical content area. Earlier AI permissions can be withdrawn separately.
Earlier features used explicit permission and a deliberate action to trigger text analysis or screenshot recognition. Requests already sent to a provider cannot be recalled remotely, and clearing app content does not delete material retained by the provider. Temporary originals used for earlier recognition are cleared after processing. Unsaved text is held only briefly, while formally saved content is managed separately by account.
Read the earlier feature notice (original, in Chinese). This historical notice explains earlier versions’ providers, what was sent, and how it was processed. It does not replace the current explanation of private and shared journals, or authorize any future AI writing feature.
Contact the operator about your content
Operator: 秦志立. For questions about access, backups, deletion, or this page, use the test support email below. Start by describing the problem. Do not email your personal recovery code or other sign-in credentials to verify an account.
Support email has not loadedContact details are read from the latest public configuration. If they cannot load, contact the administrator through the channel where you received your test invitation.
A formal public version of this test notice still requires checks of actual retention, cleanup, regional arrangements, and platform disclosures. No response deadline or immediate deletion of every copy is promised.