Basic logos storage roadmap #296

gmega · 2025-12-11T18:39:15Z

This is the bare-bones roadmap for logos storage.

emizzle

Nice! A few suggestions, but nothing blocking, so will approve now.

emizzle · 2025-12-12T08:00:28Z

content/storage/furps/frontends-filesharing.md

+1. **File sharing.** Any user in the network should be able to share files (frontend bundles and modules) such that those can be downloaded by any other user in the network.
+1. **Content addressability.** Files should be addressable by a content identifier, such that users are sure that the content they download is the content they expect.
+1. **Organic replication.** Users that download a file should be able to provide it to other users in the network.
+1. **Caching and storing.** Nodes should allow files to be either _cached_ or _stored_. Caching is constrained by a quota, and any file placed onto a node node should be cached unless explicitly told otherwise. Cached files are _evicted_ once the node runs out of quota. Optionally, a file might be marked as _stored_, at which point it no longer occupies the caching quota, and is simply preserved on disk.


Suggested change

1. **Caching and storing.** Nodes should allow files to be either _cached_ or _stored_. Caching is constrained by a quota, and any file placed onto a node node should be cached unless explicitly told otherwise. Cached files are _evicted_ once the node runs out of quota. Optionally, a file might be marked as _stored_, at which point it no longer occupies the caching quota, and is simply preserved on disk.

1. **Caching and storing.** Nodes should allow files to be either _cached_ or _stored_. Caching is constrained by a quota, and any file placed onto a node should be cached unless explicitly told otherwise. Cached files are _evicted_ once the node runs out of caching quota in a LRU manner. Optionally, a file might be explicitly marked as _stored_, at which point it no longer occupies the caching quota, and is simply preserved on disk. Storage space is limited by a separate storage quota.

emizzle · 2025-12-12T08:03:46Z

content/storage/furps/frontends-filesharing.md

+
+## Usability
+
+1. **C API.** A C API with the proper primitives for publishing and downloading files by address and pinning is published.


Suggested change

1. **C API.** A C API with the proper primitives for publishing and downloading files by address and pinning is published.

1. **C API.** A C API with primitives for publishing and downloading files by address is published.

emizzle · 2025-12-12T08:07:41Z

content/storage/furps/frontends-filesharing.md

+
+1. **C API.** A C API with the proper primitives for publishing and downloading files by address and pinning is published.
+1. **Logos Core.** The filesharing client is published as a working Logos Core module.
+1. **Zero-config networking.** Within the possibilities of current technology, user should not have to take any extra steps; e.g. opening ports on a router, to get file sharing working.[^1]


I assume that bootstrap nodes fall into this category as well?

emizzle · 2025-12-12T08:11:11Z

content/storage/furps/frontends-filesharing.md

+1. **C API.** A C API with the proper primitives for publishing and downloading files by address and pinning is published.
+1. **Logos Core.** The filesharing client is published as a working Logos Core module.
+1. **Zero-config networking.** Within the possibilities of current technology, user should not have to take any extra steps; e.g. opening ports on a router, to get file sharing working.[^1]
+1. **File search.** Accessing a file requires knowledge of a file identifier; i.e., a Content ID (CID). We assume that the user will obtain these CIDs out-of-band, either directly from other users or through an external indexing/discovery service.


Suggested change

1. **File search.** Accessing a file requires knowledge of a file identifier; i.e., a Content ID (CID). We assume that the user will obtain these CIDs out-of-band, either directly from other users or through an external indexing/discovery service.

1. **File search.** Accessing a file requires knowledge of a file identifier; i.e., a Content ID (CID). User must obtain these CIDs out-of-band, either directly from other users or through an external indexing/discovery service.

emizzle · 2025-12-12T08:15:23Z

content/storage/roadmap/index.md

+
+1. [Create A Basic File Sharing Client for Logos Core](./frontends-filesharing.md), by rolling out a minimal implementation which allows storing, sharing, and organically replicating frontends, modules, and files.
+2. [Privacy-Preserving File Sharing](./privacy-preserving-filesharing.md), where we enhance our filesharing implementation to provide privacy-preserving capabilities such as publisher and downloader unlinkability, and plausible deniability for ache nodes.
+


What about "track 3" discussed at the offsite, ie "persistence".

emizzle · 2025-12-12T08:18:26Z

content/storage/roadmap/privacy-preserving-filesharing.md

@@ -0,0 +1,32 @@
+# Privacy-Preserving File Sharing
+
+**Estimated date of completion.** Oct 2026


Fwiw, I'm not sure how much room we have here, but it feels odd to put a delivery date on a feature set that we have no idea how to accomplish.

emizzle · 2025-12-12T08:18:48Z

content/storage/roadmap/privacy-preserving-filesharing.md

+**Estimated date of completion.** Oct 2026
+
+Privacy-preserving file sharing means that:
+* neither publisher or downloader of a file can be identified as so by third parties when querying and/or retrieving data;


Suggested change

* neither publisher or downloader of a file can be identified as so by third parties when querying and/or retrieving data;

* neither publisher or downloader of a file can be identified by third parties when querying and/or retrieving data;

emizzle · 2025-12-12T08:24:43Z

content/storage/roadmap/privacy-preserving-filesharing.md

+
+Privacy-preserving file sharing means that:
+* neither publisher or downloader of a file can be identified as so by third parties when querying and/or retrieving data;
+* cache nodes cannot be held accountable for the content they cache (plausible deniability).


Suggested change

* cache nodes cannot be held accountable for the content they cache (plausible deniability).

* cache nodes should be able to convincingly deny knowledge of or responsibility for content they cache (plausible deniability).

emizzle · 2025-12-12T08:26:09Z

content/storage/roadmap/privacy-preserving-filesharing.md

+| Risk                   | (Accept, Own, Mitigation)                                                                                        |
+|------------------------|------------------------------------------------------------------------------------------------------------------|
+| We take an approach of building filesharing first and then enhancing it with privacy, and figure out that we need an different protocol altogether. | Try to identify this as early as possible and fail fast. |
+| Anon coms team builds something that does not work for us. | Close collaboration with anon coms, with the embedding of a logos storage researcher within their effort. Employ strategic and small multidisciplinary team including both cryptography and networking researchers and engineers. |


Suggested change

| Anon coms team builds something that does not work for us. | Close collaboration with anon coms, with the embedding of a logos storage researcher within their effort. Employ strategic and small multidisciplinary team including both cryptography and networking researchers and engineers. |

| Anon comms team builds something that does not work for us. | Close collaboration with anon comms, with the embedding of a logos storage researcher within their effort. Employ strategic and small multidisciplinary team including both cryptography and networking researchers and engineers. |

gmega added 4 commits December 9, 2025 07:53

chore: new structure

f5fd964

WiP

742512b

Merge branch 'v4' into feat/new-storage-roadmap

77650f1

feat: add basic roadmap

35aa7c0

emizzle approved these changes Dec 12, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Basic logos storage roadmap #296

Basic logos storage roadmap #296

gmega commented Dec 11, 2025

Uh oh!

emizzle left a comment

Uh oh!

emizzle Dec 12, 2025

Uh oh!

emizzle Dec 12, 2025

Uh oh!

emizzle Dec 12, 2025

Uh oh!

emizzle Dec 12, 2025

Uh oh!

emizzle Dec 12, 2025

Uh oh!

emizzle Dec 12, 2025

Uh oh!

emizzle Dec 12, 2025

Uh oh!

emizzle Dec 12, 2025

Uh oh!

emizzle Dec 12, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants


		## Usability

		1. C API. A C API with the proper primitives for publishing and downloading files by address and pinning is published.

	1. C API. A C API with the proper primitives for publishing and downloading files by address and pinning is published.
	1. C API. A C API with primitives for publishing and downloading files by address is published.

	1. File search. Accessing a file requires knowledge of a file identifier; i.e., a Content ID (CID). We assume that the user will obtain these CIDs out-of-band, either directly from other users or through an external indexing/discovery service.
	1. File search. Accessing a file requires knowledge of a file identifier; i.e., a Content ID (CID). User must obtain these CIDs out-of-band, either directly from other users or through an external indexing/discovery service.


		1. [Create A Basic File Sharing Client for Logos Core](./frontends-filesharing.md), by rolling out a minimal implementation which allows storing, sharing, and organically replicating frontends, modules, and files.
		2. [Privacy-Preserving File Sharing](./privacy-preserving-filesharing.md), where we enhance our filesharing implementation to provide privacy-preserving capabilities such as publisher and downloader unlinkability, and plausible deniability for ache nodes.

		@@ -0,0 +1,32 @@
		# Privacy-Preserving File Sharing

		Estimated date of completion. Oct 2026

	* neither publisher or downloader of a file can be identified as so by third parties when querying and/or retrieving data;
	* neither publisher or downloader of a file can be identified by third parties when querying and/or retrieving data;

	* cache nodes cannot be held accountable for the content they cache (plausible deniability).
	* cache nodes should be able to convincingly deny knowledge of or responsibility for content they cache (plausible deniability).

	\| Anon coms team builds something that does not work for us. \| Close collaboration with anon coms, with the embedding of a logos storage researcher within their effort. Employ strategic and small multidisciplinary team including both cryptography and networking researchers and engineers. \|
	\| Anon comms team builds something that does not work for us. \| Close collaboration with anon comms, with the embedding of a logos storage researcher within their effort. Employ strategic and small multidisciplinary team including both cryptography and networking researchers and engineers. \|

Uh oh!

Basic logos storage roadmap #296

Are you sure you want to change the base?

Basic logos storage roadmap #296

Conversation

gmega commented Dec 11, 2025

Uh oh!

emizzle left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants