Pocket Dimension · Daemonet storage
One vault.
Every drive.
No single point of loss.
Turn authorized capacity across phones, computers, a NAS, external drives, and selected off-site nodes into one client-encrypted storage fabric with explicit placement, verifiable integrity, repair, and recovery policy.
Not literally infinite. Expandable through capacity you deliberately attach.
- Raw authorized capacity
- 14.2 TB
- Protection overhead
- 5.8 TB
- Reserved device space
- 1.0 TB
- Currently unavailable
- 0.7 TB
Your personal cloud is already scattered
Stop asking which device has the file. Ask which policy protects it.
A phone brings mobility. A laptop holds the working set. A desktop brings performance. A NAS brings capacity. An off-site machine brings a different failure domain. Pocket Dimension gives each device a bounded role instead of pretending every disk is identical.
Installing Daemonet never donates storage. The owner chooses every drive, allowance, vault, network rule, and retirement action.
Phone
Recent documents, thumbnails, travel files, and narrowly scoped recovery material under battery, network, and free-space limits.
Small · mobile · intermittentLaptop
Active projects and offline files, synchronized when connectivity returns without pulling the complete archive.
Fast · selective · portableDesktop
Large working sets, creative files, game data, and background placement while the machine is available.
Fast · spacious · not always onNAS or home server
Broad archive, local-speed access, snapshots, and durable roles without becoming the only recovery location.
Large · local · continuously usefulOff-site node
Encrypted recovery material on another building, connection, operator, or region selected by policy.
Independent · encrypted · replaceableManaged capacity
A later named provider role can add availability or emergency headroom without receiving the vault key.
Separate service · explicit costHow a file enters the dimension
Protection begins before an untrusted node sees a byte.
The archive key and readable manifest remain on authorized owner devices. Storage destinations receive only the authenticated encrypted objects their exact role requires.
- 01
Encrypt locally
An owner-authorized device creates a fresh archive snapshot and encrypts content before distribution.
Plaintext boundary - 02
Chunk + authenticate
Bounded chunks make interruption, verification, selective retrieval, and repair independently manageable.
Integrity boundary - 03
Add redundancy
Use complete encrypted replicas or an owner-selected erasure threshold according to the required recovery policy.
Loss tolerance - 04
Place by policy
Select eligible devices by role, capacity, trust, network rules, and genuinely independent failure domains.
Placement authority - 05
Confirm durable writes
A destination must acknowledge the exact object; an attempted upload never counts as stored protection.
Measured state - 06
Practice restore
Retrieve enough verified material onto a clean device, reconstruct, decrypt, and compare with the expected manifest.
Recovery evidence
Preserving every encrypted object while losing the reconstruction map or owner-held key is still data loss. The encrypted manifest, key-recovery material, compatibility tools, and data placements require independent protection.
Replication, erasure coding, or both
Choose protection by consequence—not fashion.
No strategy is free. Full copies are simple and fast. Erasure coding can reduce overhead and separate fragments, but raises reconstruction and operational complexity. A hybrid can keep one fast local copy plus distributed recovery pieces.
Several complete encrypted copies
Useful for fast local restore and straightforward operations. It consumes one full unit of capacity for every additional copy.
- Home NAS copy
- Office device copy
- Selected off-site copy
Local copy plus recovery pieces
Keep the active archive nearby, then add pieces across genuinely independent locations for disaster recovery.
- Fast local working copy
- Distributed encrypted protection
- Owner-selected recovery threshold
Any threshold can reconstruct
The repository includes client-side erasure primitives. Live provider diversity and destructive-loss performance remain evidence gates.
- Illustrative: 10 total / any 6
- No node needs a useful whole
- Repair before margin collapses
The “10 / any 6” ratio is an illustrative policy—not a universal default or a durability guarantee.
Capacity with guardrails
Use the space you authorize. Leave every device room to live.
Raw disk totals are not safe capacity. The planner accounts for device reserves, redundancy overhead, unavailable nodes, watermarks, and the difference between several folders and several independent failures.
Copies count only when failures are independent.
- Not the same physical drive
- Not only the same computer
- Not only the same building
- Not only the same provider
- Not one irreplaceable phone
Repair is a lifecycle
“Self-healing” only means something when every transition is visible.
A missing device is not automatically lost, and a successful upload is not automatically durable. Pocket Dimension distinguishes temporary absence, degraded availability, threatened durability, verified reconstruction, and safe retirement.
- Risk
- A home NAS failure could make part of this example vault unavailable.
- Next action
- Reconnect an approved off-site device, attach storage, or deliberately accept reduced protection.
- Never
- Silently lower the policy and keep showing “healthy.”
Recover the data and the authority
Shards without keys are useless. Keys without shards are equally disappointing.
Pocket Dimension separates encrypted archive material from the authority that can unlock it. The owner can keep recovery artifacts, phrases, hardware keys, or later threshold shares across independent places without giving a provider a universal reset key.
Enough valid archive material
- Authenticated chunks or fragments
- Encrypted reconstruction manifest
- Enough independent available placements
- Compatible reconstruction software
Owner-controlled decryption path
- Vault key or protected recovery artifact
- Correct owner/profile binding
- Revocation-aware trusted device
- Deliberate recovery ceremony
export artifact → remove primary state → import on clean device → fetch verified objects → reconstruct → compare manifestRECOVERY IS PROVEN BY PRACTICEOne vault, familiar surfaces
The storage fabric can be sophisticated. Using it should not be.
A device needs only the working set suited to its role. The same owner-controlled archive can later appear through a local mount, synchronized folder, mobile file provider, browser session, application API, or backup workflow—when that adapter has passed its own security and recovery gates.
Pin a working set
Keep active projects or travel files available offline, then resume authenticated synchronization when connectivity returns.
Retrieve from the best eligible source
Use a nearby owner device when possible and another approved placement when the local source is unavailable.
Do not synchronize disaster
Retention, immutable snapshots, stronger mass-delete approval, and recovery credentials must remain distinct from ordinary writes.
Grant a view—not the vault
Authorize one file, album, folder, upload target, identity, device, action, or period without exposing master keys or storage topology.
Repair before unplugging
Find unique material, create and verify replacements, remove placement authority, then issue best-effort deletion instructions.
Export ordinary files and evidence
Reconstruct to ordinary storage, retain manifests and verification data, change providers, or continue through compatible open tooling.
Managed capacity without managed custody
1Man can become one replaceable storage role—not the vault.
The current pre-alpha has no 1Man object or key API. A future managed-storage offer must be separately selected, hold only owner-encrypted material, publish its capacity and retention limits, and leave enough evidence and independent placements for a credible exit.
Authoritative
Keys, readable manifests, placement policy, device membership, sharing, retention, deletion, and recovery decisions.
Always customer-controlledExact bounded role
Opaque object identifier, encrypted payload, integrity commitment, size, expiry, and the network metadata its connection inevitably reveals.
No vault key or global topologyOptional future provider
May later sell explicit encrypted capacity, availability evidence, repair assistance, or emergency headroom under a separate product contract.
Not active in private alphaLater provider network
Requires measurable independent supply, anti-Sybil controls, retrieval evidence, repair, reserve policy, and destructive node-loss tests.
Phase 10 field gate openContent encryption does not hide every shard size, upload time, network address, retrieval frequency, or total usage. Padding, batching, and privacy routes add cost and must be selected against a stated threat model—not implied by the word “encrypted.”
What recoverable actually means
Several green “synced” icons are not a recovery proof.
A vault is recoverable only when enough correct material, protected authority, compatible software, reachable placements, and a recently exercised clean-device procedure agree.
The ceiling moves only when real eligible storage is attached. Redundancy, versions, reserves, and unavailable devices consume real space.
Immediate availability depends on enough suitable nodes being reachable; an intermittently connected phone is not an always-on archive.
Encryption cannot protect a file while a compromised authorized endpoint is legitimately decrypting or displaying it.
Several drives in one machine, building, account, or administrator domain may still represent one practical failure.
Key destruction can make known encrypted copies unreadable, but software cannot prove every physical flash remnant vanished instantly.
Too few shards, lost keys, damaged manifests, incompatible software, or unreachable nodes can make an archive unrecoverable.
Storage should be a fabric—not a destination
Open the Pocket Dimension.
Start with one vault, two independent placements, an owner-held recovery artifact, and a clean-device restore. Add capacity only after the first recovery proof succeeds.
The repository path exists. A generally available personal or managed storage service still requires multi-device field evidence, supported releases, monitored repair, and destructive restore drills.