Local by design. Secure only within a deliberate boundary.
Toshokann gives derivative applications a reusable, application-scoped DBOPFS layer over the browser's Origin Private File System. It is a persistence foundation, not encryption, identity, authorization, auditing, backup, or compliance.
This project site documents storage; it does not open it.
Live GitHub Pages site
Documentation only
The pages at thewizardnexus.github.io/Toshokann/ publish project documentation, shared appearance files, license records, and the knowledge-hall image. They do not ship or execute Toshokann's library runtime, DBOPFS modules, local-document store, or reference extension.
Derivative application
Local runtime storage
A packaged Library or Archive derivative includes the neutral runtime and stores its browser-local working collection through application-scoped DBOPFS over OPFS. The derivative owns the application identity and every policy governing that data.
02
Persistence model
DBOPFS organizes records beneath one application identity.
Database layer
DBOPFS is a lightweight database abstraction over OPFS. Tables are directories and records are files containing serialized application values.
Application scope
A canonical application identity selects apps/<id> beneath the origin's OPFS root. This prevents accidental name collisions among cooperating applications.
Browser scope
OPFS belongs to the browser's storage key, which is based on origin. URL paths do not create separate origins, so browser-hosted projects beneath thewizardnexus.github.io share an origin and its storage boundary.
Native scope
A native host can strengthen separation with a distinct WebView profile and a host-bound application identity. That is a stronger boundary than directory organization inside one same-origin browser profile.
Worker path
The optional OPFS worker moves supported file operations off the main thread. It improves responsiveness; it does not add confidentiality or a separate security principal.
Know exactly what the foundation does and does not establish.
Foundation mechanics
What Toshokann provides
Application-scoped local persistence through DBOPFS and OPFS
Canonical application identity checks before opening storage
Serialized DBOPFS writes and managed library seed operations
Bounded ranked Markdown context with explicit untrusted-data framing
An explicit, user-invoked backup and restore mechanism when a derivative exposes it
Derivative controls
What Toshokann does not provide
Encryption at rest or in exported backups
Authentication, identity proofing, RBAC, or need-to-know enforcement
Audit logging, nonrepudiation, legal hold, or records governance
Guaranteed retention, secure deletion, recovery, or disaster-resilient backup
Automatic privacy, regulatory, preservation, or security compliance
04
Data lifecycle
Browser-local does not mean permanent or secret.
Quota and eviction
Browser storage is subject to implementation-specific quotas and eviction behavior. A device under storage pressure may remove best-effort data.
Persistence request
Toshokann's DBOPFS layer may request persistent storage through navigator.storage.persist(). The browser may deny the request; even a grant is not a backup or protection from explicit user clearing.
User clearing
Clearing site data, deleting a browser profile, resetting an application profile, or uninstalling a host can remove the local collection.
Backup export
If the inherited DBOPFS backup API is exposed, it serializes tables as JSON, compresses the bytes, and encodes them in a PNG file. Compression and PNG encoding are not encryption: treat the export as plaintext-equivalent sensitive data.
Restore
A restore can overwrite records with matching keys. Derivatives should authenticate and validate a backup before accepting it, confirm scope with the user, and retain recovery evidence appropriate to their risk.
Build the boundary around the information, not around the storage API.
01
Separate applications that should not trust one another
Use dedicated origins for browser deployments or separate native WebView profiles for stronger isolation. Do not rely on URL paths or apps/<id> directories as access control.
02
Control executable code
Use a restrictive Content Security Policy, minimize third-party scripts, pin and review dependencies, prevent executable collection content, and treat XSS prevention as protection for local records.
03
Add encryption where the risk requires it
Use device encryption and, when appropriate, application-layer encryption with keys stored separately from the ciphertext. Do not embed decryption keys in the application bundle or the same exported backup.
04
Own retention and recovery
Define approved backups, restore testing, retention schedules, deletion procedures, incident response, and migration plans. Verify that operations match the institution's policy.
05
Add identity and governance
Implement authentication, authorization, audit, approvals, classification, dissemination, privacy, records, and legal controls outside the neutral core, and test them as part of the derivative.
06
Protected and regulated information
Do not place sensitive holdings into a control environment that has not earned them.
Fusion centers, public-safety partnerships, ISACs, ISAOs, schools, companies, governments, and other institutions can use Toshokann for information already approved for their deployed boundary. The neutral foundation is not, by itself, suitable for classified information, CUI, criminal-intelligence records, protected student or health data, TLP enforcement, regulated evidence, secrets, or other controlled holdings.
A derivative intended for protected use needs a documented threat model, approved hosting and device posture, identity and access enforcement, audit and incident response, release and dissemination controls, encryption and key management, backup and deletion governance, legal review, and any required assessment or authorization.
