starred/anything-llm

Fork 0

mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-03-02 22:57:05 -05:00

[FEAT]: Add link to open file in citations #2343

New issue

Open

opened 2026-02-28 06:04:28 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-28 06:04:28 -05:00

Owner

Originally created by @devbysb on GitHub (Apr 3, 2025).

What would you like to see?

Hi, I really appreciate this project, but there's one little thing missing. When you get a response, there are quotes with the text found. Would it be possible to display a link to view the file? This would allow documentation containing screenshots to display them :) If this option could be available both in the interface and in the widget, with an enable/disable setting, that would be perfect.

Thanks

Originally created by @devbysb on GitHub (Apr 3, 2025). ### What would you like to see? Hi, I really appreciate this project, but there's one little thing missing. When you get a response, there are quotes with the text found. Would it be possible to display a link to view the file? This would allow documentation containing screenshots to display them :) If this option could be available both in the interface and in the widget, with an enable/disable setting, that would be perfect. Thanks

deekerman added the

enhancement

feature request

Desktop

labels

2026-02-28 06:04:28 -05:00

deekerman commented

2026-02-28 06:04:31 -05:00

Author

Owner

@timothycarambat commented on GitHub (Apr 3, 2025):

Hi, I really appreciate this project, but there's one little thing missing. When you get a response, there are quotes with the text found. Would it be possible to display a link to view the file? This would allow documentation containing screenshots to display them :) If this option could be available both in the interface and in the widget, with an enable/disable setting, that would be perfect.

This is impossible in the Docker-based version since we cannot open local files from a browser environment - and the file may even no longer exist since in the docker version is could have been added by any other user/admin.

This would have to be limited to desktop only.

@timothycarambat commented on GitHub (Apr 3, 2025): > Hi, I really appreciate this project, but there's one little thing missing. When you get a response, there are quotes with the text found. Would it be possible to display a link to view the file? This would allow documentation containing screenshots to display them :) If this option could be available both in the interface and in the widget, with an enable/disable setting, that would be perfect. This is impossible in the Docker-based version since we cannot open local files from a browser environment - and the file may even no longer exist since in the docker version is could have been added by any other user/admin. This would have to be limited to desktop only.

deekerman commented

2026-02-28 06:04:33 -05:00

Author

Owner

@therealtimex commented on GitHub (Apr 5, 2025):

I understand your point about the Docker environment limitations, but I think there might be a middle-ground solution using database storage. Instead of directly linking to local files (which wouldn't work in Docker), the system could:

Extract and store text/content from referenced files in a database
Create unique identifiers for each stored content piece
Generate links that open this content in a viewer within the application

This approach would work consistently across both Docker and desktop environments since it doesn't rely on local filesystem access. The content would be stored within the application's data layer rather than depending on external file access.

For screenshots specifically, these could be stored as binary data in the database and rendered in a viewer when needed.

Would this alternative approach address the core need while maintaining compatibility with the Docker environment?

@therealtimex commented on GitHub (Apr 5, 2025): I understand your point about the Docker environment limitations, but I think there might be a middle-ground solution using database storage. Instead of directly linking to local files (which wouldn't work in Docker), the system could: 1. Extract and store text/content from referenced files in a database 2. Create unique identifiers for each stored content piece 3. Generate links that open this content in a viewer within the application This approach would work consistently across both Docker and desktop environments since it doesn't rely on local filesystem access. The content would be stored within the application's data layer rather than depending on external file access. For screenshots specifically, these could be stored as binary data in the database and rendered in a viewer when needed. Would this alternative approach address the core need while maintaining compatibility with the Docker environment?

deekerman commented

2026-02-28 06:04:33 -05:00

Author

Owner

@timothycarambat commented on GitHub (Apr 5, 2025):

It has been mentioned many times historically, but there is a reason we do not do full copies of documents. The main reason is bloat since it would be document duplication. Often we can take a 30mb PDF and text extract it to a couple hundred kb. After a document has been uploaded this text-only copy is present though, and we could show the raw data of that, but certainly not within a native viewer on the user side.

It would probably look more like the raw.githubusercontent kind of links, where it just shows the raw text. Often though we will strip readable whitespace since that does not impact LLM inference - so the text may not be human-readable doing this.

@timothycarambat commented on GitHub (Apr 5, 2025): It has been mentioned many times historically, but there is a reason we do not do full copies of documents. The main reason is bloat since it would be document duplication. Often we can take a 30mb PDF and text extract it to a couple hundred kb. After a document has been uploaded this text-only copy is present though, and we could show the raw data of _that_, but certainly not within a native viewer on the user side. It would probably look more like the raw.githubusercontent kind of links, where it just shows the raw text. Often though we will strip readable whitespace since that does not impact LLM inference - so the text may not be human-readable doing this.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/anything-llm#2343

No description provided.

Rows
Columns