File Attachments Proposal

[ryneeverett]

It would be handy if it were possible to attach files to a task. Personally, I would mostly use it for text files, pdf's, and images.

I found #786 which alludes to this but no more recent discussion. One of the main benefits and challenges which doesn't seem to be considered there is synchronization.

While storing files separately from the database is the most performant solution, I doubt the additional complication of the synchronization and storage system would be worth it. Files could be stored as blobs if we set a reasonable size limitation (1gb?). The first problem I'm aware of is that I think we'd need some additional logic in taskchampion to batch large operations that are too big to reliably fit on the wire and then reassemble them on the other end.

From a user interface perspective, I would see this working a lot like annotations, except a file path is given rather than a string and it is stored with a timestamp.

task attach <filter> <name (if omitted use file name)> <path (if omitted open xdg file chooser)>
task open <filter> <name> <application <if omitted try xdg-open)>

[djmitche]

I suppose there are two use-cases for this, which we would need to distinguish: a small text file containing notes on the task, or arbitrary (potentially binary) files. For the former, we could do a reasonable job of "synchronizing" them, using operations like "insert string S at position N" and "delete K characters at position N". This is pretty standard OT stuff, although most of the research assumes that you get to see the user's editing behavior (think etherpad or google docs). We could probably adapt some kind of character-by-character diff approach to turning edits into operations.

For the latter, we would want to do wholesale replacement of the object, with latest-write-wins semantics. Trying to model replacement of one PDF with another as byte-stream edits would be pretty inefficient.

For latest-write-wins, I think we could just us some kind of content-addressable storage approach, storing only the content hashes in the operation stream. So maybe an attached file looks like "att_rfp.pdf": "441c1e3a8ddb7b12c5d48a9c724df0e1c326621b00b43ebb2d227aa2c5650a64faf4fc946534356b4da90294fac60dbf1a7bf2d21bcd35e3412a4c08b69fee72". Updates to a file would just change the hash as a sync operation. The files themselves would be uploaded, encrypted, to the server as a separate API. This is trivial for object-storage (AWS, GCP) and pretty easy to add for taskchampion-sync-server. The server could apply its own size maximum. We would need to think about garbage collection of old objects, but that's not insurmountable.

The downside is, users will be tempted to task 1 attach notes.txt and edit those notes as the task proceeds -- and the last-write-wins semantics will eventually surprise them.

[djmitche]

Hyrum's Law suggests someone will use it for notes, whether we intend to or not!

Locally, they could be stored in the database -- although SQLite's performance with 1GB files might be poor, so we could consider storing them as files on the fs too. My comment was only talking about sync.

As for compression -- yes, compression is always warranted and done before encryption. That might be counter-productive for already-compressed files, but I think modern compression algorithms handle that case with pretty minimal overhead.

[ryneeverett]

Hyrum's Law suggests someone will use it for notes, whether we intend to or not!

IMO that person can't complain about last-write-wins conflict resolution.

But also, I think the client can make it clear that the user is replacing and not editing. I would envision writing the file to /tmp as read-only when they open it. They would have to save it elsewhere and re-attach it to "modify" it.

My comment was only talking about sync.

My comment was responding to these lines:

The files themselves would be uploaded, encrypted, to the server as a separate API... We would need to think about garbage collection of old objects, but that's not insurmountable.

It seems like the separate API and garbage collection considerations wouldn't be necessary if we treated files like normal data attributes. The only additional consideration would be handling larger operations than we're currently equipped for.

[djmitche]

Good point about making the semantics clear.

If the files are normal task attributes, that's potentially a lot of garbage -- every task attach would generate an operation of that size, and even if that file is overwritten the operation creating it would remain in the operation stream.

But for "reasonably-sized" files this might be fine. Maybe to help ensure that we should have some kind of max-file-size config, where users can increase it if they want to but hopefully with the awareness that things might get slow and/or big.

[ryneeverett]

If the files are normal task attributes, that's potentially a lot of garbage -- every task attach would generate an operation of that size, and even if that file is overwritten the operation creating it would remain in the operation stream.

By encouraging large task attributes we're magnifying some aspects of taskwarrior that might already be problematic:

• storage usage is doubled by storing all data both in operations and in the working set
• we might be lacking a satisfactory system for purging old data (Seems like there have been a number of issues opened about this in the last couple years but I don't recall to what extent they are resolved.)

Let me know if I've misinterpreted you.

[ryneeverett]

An advantage of the separate API for files is that there could be an option to synchronize files lazily which would be ideal for low-storage devices. (phones)

[djmitche]

Could attachments just be URLs, maybe with some convenience support for things like GitHub Gists, Google docs, Pastebins, etc.?

[smemsh]

I think this route is tantamount to saying, "taskwarrior's sweet spot is small strings, if you need files use something else". There's merit to doing one thing well and avoiding bloat.

I tend to think exactly that ("if you need files, use something else"). I.e. that taskwarrior was more used to store references to things rather than content, unless they are small strings. If Taskwarrior starts becoming an arbitrary content store, the whole requirements change and many different usage scenarios emerge. A lot of different scripts are doing a full export and processing that every time. This works fine when export is small. Of course this is a solvable problem with different export modes, but just an example. Not opposed to idea, but seems like big change. Maybe only people that use the features would be impacted.

Perhaps we could support different reference types, and then a handler could be configured, and possibly an internal implementation available for some reference types (but could be overridden by external handler, or internal handling disabled). For example we have string, numeric, date, duration, we could add new types like "url" or "s3" or "file" which would be remote references. Then ways to launch handler defined in rcfile and some kind of json or argv-based interface? We could add a different type than "string" that is a "string plus" that gets scanned for URLs that are specified according to standard RFC-defined syntax, the scheme/netloc/path/params/query could be extracted and handled for those found and configured (or menu presented, etc).

Anyways just thinking out loud... I currently use a tool that just scans for urls in annotations and will give a select and open those found, this was simple to write but I do take the point that not everyone should have to write such a script or find one. There is also something to be said for using the system url-opening script (like "open" or "xdg-open") to do the scheme parse and dispatch to handler.

[djmitche]

There's a data scheme for URLs, which contains the data it represents, and can be used for small things like data:text/plain,lots of text. So supporting URLs might also support small embedded data, with a reasonably easy explanation that storing your RAW photos as data URLs is not a good idea.

Unfortunately,

⸩ xdg-open 'data:text/plain,lots of text'
gio: data:text/plain,lots of text: The specified location is not supported

[ryneeverett]

If Taskwarrior starts becoming an arbitrary content store, the whole requirements change and many different usage scenarios emerge.

This is a good point to keep in mind. I do think the use cases for taskwarrior ought to evolve/expand, but there might be other directions/proposals that move the ecosystem more gradually.

[smemsh]

There's a data scheme for URLs

Neat, looks like a urlencoded blob with a mime type, optionally base64 encoded. Yeah, people could indeed use that to stuff documents if they wanted, that's an interesting idea. It would have to be multi-valued right? Like annotations are currently.

Would it surface as a UDA (add "url" to list of types?) or just be a built-in specific well-known field name? I don't see any way to add a multi-value UDA currently (like how annotations are multi-valued), but that seems like a better way, potentially several could be added by the user with different names (for different categories of references: 'files' and 'notes' for example).

What about support inside strings (like annotations?) It's kind of a different question I suppose. Once the machinery is there to handle URLs, it could be discussed separately on how to support "extract and select" from annotations.

[xdg-open support for data scheme]

isn't it just a matter of registering it? I believe you can configure that stuff with xdg-open, like you put a file in .local/share/applications/defaults.list and run some xdg-mime commands to install a text/plain handler for that scheme, or something like that. In any case if we could configure the "thing that handles urls" then it could be an arbitrary program that worked properly.

I do rather like just being able to give a task uuid to something though and have it give me a list of urls to select from and open, I think that feature should maybe be supported internally in taskwarrior in like "task N open" command or something like this, which would create a menu from the url data types, and maybe optionally scan annotations for urls as well to add to the list.

We should keep in mind also, if the interface to xdg-open(1) or whatever is execve(2), passing data urls means we are subject to limitations thereof, such as looks like limit per string is 32 pages on linux if I understand right! Smaller documents indeed. We could use pipes and json like current stuff, but xdg-open does not support that of course. Not sure what else is out there but if it's not using the stock system "mime switch" then it's kind of back to the same issue that there's no standardized external tool. But this limitation would only be specific to people using data-scheme URIs, not ordinary ones.

[smemsh]

yeah so I guess you do like this:

 $ cat .config/mimeapps.list
[Default Applications]
x-scheme-handler/data=datascheme.desktop

 $ cat .local/share/applications/datascheme.desktop 
[Desktop Entry]
Name=datascheme
Exec=/bin/echo %U
Type=Application
Terminal=false
MimeType=x-scheme-handler/data

 $ DISPLAY=:0 XDG_UTILS_DEBUG_LEVEL=2 xdg-open data:foobar 
Selected DE generic
Checking /home/schemetest/.config/mimeapps.list
data:foobar

So, it will pass the whole url. You have to have DISPLAY set, which is lame, but it's hardcoded into the script, at least Ubuntu24's. Also, I can find no mechanism to choose an executable for scheme+type, it's just scheme. So the dispatched handler would need to unwrap the scheme and encoding itself, so now user will have to take steps and find a script just like before.

I dunno, xdg-open is really not very nice, has these limitations, and many fork/exec happens for every run. Actually a bit sad that's all we have in 2026. Also what will happen on Windows? Might be better to handle a few url schemes internally. Now we're back to the beginning :-)

[linuxcaffe]

Sounds like you're trying to reinvent taskopen. https://codeberg.org/jschlatow/taskopen

…

On Sat., Feb. 21, 2026, 6:18 a.m. Scott Mcdermott ***@***.***> wrote: yeah so I guess you do like this: $ cat .config/mimeapps.list [Default Applications] x-scheme-handler/data=datascheme.desktop $ cat .local/share/applications/datascheme.desktop [Desktop Entry] Name=datascheme Exec=/bin/echo %U Type=Application Terminal=false MimeType=x-scheme-handler/data $ DISPLAY=:0 XDG_UTILS_DEBUG_LEVEL=2 xdg-open data:foobar Selected DE generic Checking /home/schemetest/.config/mimeapps.list data:foobar So, it will pass the whole url. You have to have DISPLAY set, which is lame, but it's hardcoded into the script, at least Ubuntu24's. Also, I can find no mechanism to choose an executable for scheme+type, it's just scheme. So the dispatched handler would need to unwrap the scheme and encoding itself, so now user will have to take steps and find a script just like before. I dunno, xdg-open is really not very nice, has these limitations, and many fork/exec happens for every run. Actually a bit sad that's all we got in 2026. Also what will happen on Windows? Might be better to handle a few url types internally. Now we're back to the beginning :-) — Reply to this email directly, view it on GitHub <#4038 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAR6S63F2DEGRHVKSG4W6TT4NA5IZAVCNFSM6AAAAACSXRMRKSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOBYGAYDMMA> . You are receiving this because you are subscribed to this thread.Message ID: <GothenburgBitFactory/taskwarrior/repo-discussions/4038/comments/15880060@ github.com>

[smemsh]

Right, as we mentioned in #4009 where we discussed taskopen and various other scripts. point is maybe some subset of stuff should be brought in to taskwarrior. I mixed these two because there was an idea that one could solve both with URL support.