External file references. Link files instead of importing copies

Feature Requests
1

WHAT DO YOU RECOMMEND?

A File Object that references a file instead of importing a copy of it.

Today, associating a file with an Object has exactly one path: upload, which pulls a copy into the space’s internal store. For files that already live somewhere else — a local folder, a NAS, a cloud drive — this creates permanent duplication between Anytype and the filesystem. Deduplication inside a space does not help, because the duplication is between Anytype and everything outside it.

The file:/// workaround exists but is only a website link: no file type, no preview or thumbnail, not an Object, not filterable in Sets, and dead on mobile.

HOW COULD IT BE DONE?

A reference File Object stores a URI plus cached metadata (name, size, type, thumbnail, last seen) — but not the file bytes.

The key is that the URI scheme should be pluggable, so this is one mechanism rather than one integration:

Scheme Resolver
file:// local path, with per-device root mapping
webdav:// Nextcloud, ownCloud, Synology
s3:// S3 / MinIO / Backblaze
gdrive://, onedrive:// OAuth cloud providers

Google Drive is the one I would use, but I am deliberately not asking for a Google integration. Providers can land one at a time, and the community can build the rest.

Expected behaviour:

  • references behave like File Objects everywhere — linked from any Object, shown in relations, filtered in Sets and Collections, found in search
  • cached metadata keeps the Object useful and searchable when the source is unreachable, showing a clear “unavailable” state rather than an error
  • per-device path mapping for file://, so one Object resolves on a laptop and on a NAS without rewriting anything
  • read-only by default — Anytype never moves or deletes source files
  • explicit conversion both ways: “import a copy of this reference” and “export this file and replace it with a reference”

Natural follow-up once references exist: point a Collection at a folder and let Anytype maintain reference Objects for its contents automatically. Separate request, but it is where this leads.

REAL WORLD USE CASES

Purchase tracker. I keep one Object per device — model, purchase date, price, warranty, shop URL — and each should carry its invoice and user manual. Those PDFs already exist on disk in a structure other tools depend on: my accountant needs “all invoices from 2025” as a folder, my backup tooling operates on those folders, other applications open the same files, and the file names follow a convention (2026.03.12 Switch_TP-Link_SG1005P-PD.pdf) that my scripts parse. Every document now exists twice, and the copies drift apart the moment I replace a scan or fix a name.

Document archive. Invoices arrive from a scanner or an email rule into a watched folder. With references, the Object points at the file and stays correct no matter what re-sorts or renames it later. With uploads, every re-sort silently invalidates what Anytype holds.

Media library. Cataloguing a photo, music or video collection is impossible today — nobody will duplicate hundreds of GB into a space to get a catalogue of it.

The common thread: Anytype should be able to describe files without becoming the only door to them.

RECOMMENDED ALTERNATIVES

file:/// website links. Works today, but it is a link, not an Object — no preview, no queries, nothing on mobile.

Uploading copies and living with duplication. What I do now. It breaks as soon as a document is corrected or renamed on disk, and there is no way to detect the drift.

Moving to Obsidian. This is the alternative that actually solves the problem, and it is worth describing precisely, because it shows what users expect. In Obsidian a vault is a directory. You point the app at an existing folder and everything already in it becomes part of the vault immediately:

  • existing PDFs and attachments are picked up in place — no import step, no copy
  • notes reference them by ordinary relative paths, so references survive the folder being moved, synced or backed up as a unit
  • files written by other programs — a scanner, a sync client, a shell script — simply appear on the next scan
  • the folder stays fully usable by every other tool on the system
  • there is no second copy to keep in sync, because there is no first copy

The cost of switching is typed Objects, relations, the graph and E2EE sync. I do not want to make that trade, but ADDITIONAL CONTEXT

This does not conflict with local-first or E2EE. A reference stores a URI and cached metadata; resolution happens locally on each device, with credentials held per-device and never synced. The encrypted space is unchanged, and users who never create a reference are unaffected.

I am not asking for Obsidian’s architecture. Anytype’s storage is content-addressed, encrypted and syncable, and a directory-as-space model would break all three. That is precisely why the request is for references rather than vaults: same outcome — files stay put, other tools keep working, no duplication — without touching how uploaded files are stored today.

It closes a gap the API cannot work around. An integration can push a file through upload-file, but it has no way to express “this Object concerns that file over there” without adding another copy to the space.

Related requests worth linking: auto-backup / auto-export, and deeplinking for external apps — the same theme of Anytype cooperating with files and tools that live outside it.

2

Thanks for the detailed feature request here.

I would add that we’ve recently been looking at the feature ‘replace file’ while preserving all links—this would solve a specific use case well. The issues that surround it are race conditions and offline problems. However it doesn’t address the ‘no duplication’ issue.

Issues with file references to local files is that it doesn’t play nicely when you’re accessing your spaces from other devices (mobile) and if you’re collaborating with others.

While storing links to files hosted on the cloud is a solution, which effectively works today, it doesn’t play nicely from a local-first standpoint.

There are a lot of architecture and security challenges to think about as well.

3

Thanks — that’s more useful than I expected, and it points at a better shape for this.

On collaboration you’re right, and I’ll concede it. A reference that resolves for one member and not another is a bad experience.

But I think the objection can be designed around, rather than worked around. Instead of “reference instead of copy”, treat it as levels of fidelity:

  • every File Object always carries a small, fully synced representation — thumbnail, first page, metadata
  • optionally, it also carries a reference to the full-fidelity original

This doesn’t break your invariant. A File Object stays readable on every device and in every shared space — the only question is at what resolution. That makes it a parameter rather than an exception, and it works the same in a shared space: everyone sees the preview, only members whose device can resolve the URI open the original.

It’s also a familiar pattern rather than a novel one — Apple Photos’ “Optimise Storage” and Lightroom’s smart previews both work this way, and users already understand it.

Two things I’d get right if you ever pick this up: preview fidelity should be per-Object (thumbnail / first page / full preview), because for some documents the first page is the sensitive content; and the preview should be generated once at attach time rather than regenerated per device, which I think avoids the race conditions you mentioned.

On ‘replace file’ — I’d take that on its own. It solves the drift half of my problem even without the duplication half. Will it be exposed through the API? A script that watches a folder and updates the corresponding Object would cover most of my use case.

4

This should be technically feasible, it’d require client side processing which is a thing in itself. What I’d argue here is that it’s halfway solution that I’m not sure what one is optimising for. If you’re in a collaborative environment and you upload various local PDFs as previews, what purpose does that serve to others (e.g. you give your accountant previews of your expenses, but not the whole thing)? It would be annoying for the other user to have to message the uploading user for the whole file. Would this not be better served by:

  1. Uploading the whole file to a secure cloud accessible location.
  2. Uploading the whole file to Anytype.

What is a little less clear is the problem definition, there seems to be multiple mixed together here and it’s difficult to optimise for all of them. Broken links is more eloquently resolved with a replace file feature while duplication is primarily a matter of storage space or centralisation (one can buy more from membership, self-host, or use a third party solution with link references).

5

Let me correct my own request, because I shrank it past the point where it’s worth your time.

Pasting a URL into a text relation already works. So “let the File relation accept a URL” on its own isn’t worth building — you’d be adding typing to something I can already do by hand.

What I’m actually asking for is a file picker: attach a file to an Object, choose “from Google Drive / OneDrive” instead of “upload”, pick the file, done. Anytype stores a reference; the file never enters the space.

The reason this isn’t just convenience is the kind of link it produces. When I copy a URL from the browser I get a share link — it breaks when permissions change, when the file is renamed, when it’s moved to another folder. A picker returns the provider’s stable file ID, which survives all three. So a picker is not a faster way to get the same link; it’s the only way to get one that doesn’t rot. Given that broken links are the problem you said you’re actively looking at, that seems relevant.

Against the objections raised so far: an https reference resolves on mobile, and it resolves for every member of a shared space who has access to the underlying folder — including the accountant, who gets the whole file rather than a preview. No client-side processing is needed. OAuth tokens would be per-device and never synced, which I think fits your security model rather than fighting it.

On local-first: bookmarks already store a URL whose content lives elsewhere and needs a network to read. If that’s acceptable, a reference to a PDF has the same properties.

On cost — Google Picker API and the OneDrive File Picker SDK are both embeddable components rather than something you’d build from scratch. And one provider would be enough to prove the shape; it doesn’t have to be all of them at once.