1. Scope
This notice describes how SolidFish handles information when a sender creates a share, a recipient opens one, a person previews a shared link, or someone contacts support.
SolidFish is designed for identity-light sharing of fleeting information. A standard handoff does not require a public SolidFish profile, but that does not mean the service provides complete network anonymity: limited technical, security and operational metadata may still be processed as described below.
SolidFish is not intended to be a permanent document archive, account-based file store, or records-management system. Shares are given an intentional lifetime so data does not remain active simply because indefinite storage is the default elsewhere.
2. Package content
Package content may include uploaded files, a note, web links, an optional introductory message, and generated previews required to present supported content safely.
Content is processed only to provide the requested sharing, viewing, conversion, delivery, abuse-handling, and deletion functions. Original files and generated previews are identified separately.
3. Service metadata
SolidFish records limited operational metadata needed to issue and resolve a Solid Code, enforce expiry, protect recipient access, apply rate limits, process delivery, and investigate service failures or abuse.
- Package creation, expiry, claim, deletion, and processing timestamps.
- Hashed recipient-password and management-key verifiers, never the raw credentials.
- File type, size, processing state, and delivery outcome.
- Security events such as repeated invalid credential attempts and temporary lockouts.
- Technical request data needed for security, reliability, and troubleshooting.
4. Retention and deletion
Shares are retained until their configured expiry, one-time completion, or earlier sender deletion. Expired and deleted objects are queued for removal from active storage.
This intentional lifetime is part of the product design: fleeting information should not become permanent simply because storage is available. Reducing unnecessary persistence is also part of SolidFish's environmental philosophy, but SolidFish does not claim a specific carbon, energy or storage reduction unless that outcome has been measured and substantiated.
Operational logs, security events, delivery records, backups, and abuse records may follow separate limited retention schedules where needed for service operation, security, abuse handling, legal obligations, and recovery. These records are not kept as a substitute for the share itself.
5. Information kept in your browser
The public web application may store recent Solid Codes, the selected visual theme, and an optional protected local management reference in the browser.
Recent-code history and theme preferences are not synchronised between devices. Clearing browser data removes them. A management key should only be retained locally through the protected-storage option when that feature is available.
6. Recipient email delivery
When a sender provides recipient email addresses, SolidFish uses them to deliver the Solid Code and related package information. Recipient passwords and management keys are not included in delivery messages.
Delivery status and provider response metadata may be retained long enough to diagnose delivery failures and prevent abuse.
7. Support, feedback, and abuse reports
Contact submissions include the information entered into the form and technical metadata needed to respond. People must not submit recipient passwords, management keys, or unnecessary copies of private content.
Abuse reports may be retained for investigation, service protection, legal obligations, and repeat-abuse prevention.
8. Service providers and disclosures
SolidFish may use hosting, object-storage, email-delivery, security-monitoring, and support providers to operate the service. Providers receive only the information required for their function and are subject to contractual controls.
Information may also be disclosed when required by law, to protect people or the service, or as part of a documented corporate transaction.
9. Your choices and requests
- Senders can choose expiry and may delete an active package with the management key.
- Recipients may choose not to open a package or follow a shared link.
- Browser history and theme preferences can be cleared locally.
- Privacy questions and applicable data-rights requests can be submitted through Contact.
10. Changes to this notice
Material changes to this notice will be published with an updated effective date before or when they take effect, subject to legal and operational requirements.