Image Upload

[LukasKnuth]

We can currently embed images on a page using normal markdown syntax like [description](image-url.png).

This requires that the image be hosted elsewhere on the internet already, and is publicly available from there. Are there any plans to support uploading images to pages directly through the editor?

Perhaps like GitHub supports by drag/drop of the image directly into the editor.

[irskep]

@cu I can work on this. I've done image upload features in a few web apps using framework-less JS. In this case I assume it's fine to store the data directly in sqlite rather than requiring an additional service.

[cu]

I've thought about this but haven't implemented it yet because it's fairly complicated and I almost never need to put images in my notes. On the few occasions that I really want an image, I have done as Lukas suggests and uploaded it somewhere else.

So I'm not entirely opposed to adding image uploading support but I'm a bit nervous that a proposed solution may not quite meet the standard of threadbare minimalism that Silicon aspires to. :) For example, these are some of the questions I've pondered so far:

---

Where do the images live? In SQLite or on the filesystem next to the database?

There are pros and cons to each approach, although I think the balance is slightly in favor of the DB. It keeps all Silicon data in one place and it means we don't have any additional worries about managing files via Python code. Especially where security is concerned.

On the other hand, I have been toying around with the idea of reworking the storage layer to address the concern that changing one character on a long page results in a whole new complete copy of that page being saved. I'm nowhere near an actual solution that I can stomach but it would almost certainly mean moving all but the most recent copies of pages out of SQLite and onto the filesystem in some form. (The current copies would stay because SQLite's full text search is too awesome to give up.)

Are images attached to a specific page, or do they go to a general image store that all pages can use?

Per-page likely means shoving image management functionality into the sidebar somehow, which could get tricky from a UI perspective. But it's the one I'm leaning furthest toward.

A wiki-wide image store means writing a file manager which can be a nontrivial task. So if you're working on a page and decide to upload an image, that means going to a different page to manage your media. Unless it can be implemented as an overlay "window" of some sort.

Do we allow uploading all kinds of files, not just images?

If it's just images file types, which ones?

Handling image links?

The edit page can only handle text, so is it okay to require the user to copy and paste a link to the image? Could we drag and drop the link into CodeMirror somehow? (The textarea variant will always be copy-and-paste of course.)

---

Basically I'm open to ideas and mockups but can't promise with 100% certainty that my version of Silicon will support image uploads at this point. But I will say that the more design discussion that happens before any implementation is written, the more likely it is that I can merge it in.

[irskep]

I believe images can be done in the spirit of "threadbare minimalism" without sacrificing too much UX, and storing images in the wiki itself vs another service is also great future-proofing against commercial web services that won't be around forever.

Storage

It's easy to defer any decisions about where the images are stored. Ultimately it's either "open file" or "read database row" with no change to the HTTP requests and responses. Conceptually, I like the idea of "the database is the entire wiki."

Management model

Presenting a mental model of "managing" images is harder. Wiki-wide media management requires more UX than I think this project should be trying to support, especially if you're trying to avoid much JS.

I wrestled with the global-gallery vs page-gallery problem in another one of my projects. Originally, I used a global gallery of images that you could pull into individual pages (which, like in your project, are in Markdown via CodeMirror). After living in this world for a while, I changed my mind, ripped out the global gallery, and went all-in on galleries tied to specific places. The global gallery doesn't add much value but requires a lot of code.

On the other hand, tying images to specific pages has advantages:

1. Obvious UX options for listing images and letting users take action (the sidebar, maybe collapsed by default)
2. You don't need to prevent users from linking to images across pages, but the URL will still signal "page ownership" (e.g. /image/home/logo.jpg vs just /image/logo.jpg
3. You could potentially auto-delete unused images based on what's still referenced in the Markdown. Maybe this is too much magic. Maybe you could mark images as "unused" and let the user delete them if they want.

For this strategy, I'd guess maybe 50 lines of Python and 50 lines of combined HTML/JS/CSS.

File types

As a user, I would be unsurprised to be limited to the image/* MIME types. There's value in being a general file store, but this project isn't trying to do everything.

Links, drag and drop, etc.

In JS, you can write your own drop handler that only handles specific file types. You would then use this to upload the file with some loading indicator, and then insert a link into CodeMirror.

As I mentioned earlier, having canonical image URLs that include the page slug they live on makes sense to me.

I'll probably whip up a prototype soon and you can let me know what you think.