imgur / image-upload API specs

Post by John
The recent decision by imgur to delete non-account-associated uploads
got me thinking about WWW resource persistence and self-hosting yet
again. People used imgur because it was convenient and free; uploading
an image and sending a link was a simple process.

It wasn't convenient for me receiving those links. Links to Imgur
images don't work without Javascript, so not in my preferred
lightweight web browsers, and even in Firefox it takes ages to load,
and (with my configuration, at least) sometimes a few page reloads.
99% of the time I just ignore Imgur links, and for the other 1% it
usually turns out that it wasn't worth the effort.

Post by John
Imgur also had an API which applications could integrate with, so for
example flameshot can just upload your screenshots directly to imgur if
desired. Most of these applications just assume you're uploading to
imgur, but if some other server implemented the same HTTP API endpoints,
it would be a drop-in replacement--but I haven't heard of anything like
that!

If the applications are hard-coded to use the Imgur server, would
changing the server really be much harder than replacing that code
with a dead-simple HTTP POST to another server, without the fancy
API?

Post by John
Is anyone aware of open-source servers which implement an
Imgur-compatible API, or of efforts to define a "standard" set of
endpoints for image uploading and retrieval?

Why does it need to be a standard? HTTP makes this very easy to
build from scratch, it's a typical HTML form example task. If Imgur
makes it so complicated that it could be its own standard, that's
their problem. Rip all that out and put in something sensible
instead!

A quick search suggests that Imgur use OAuth 2 in the API for
restricting API access, so that's just for their own benefit.

Even better, set up an SFTP (FTPS, FTP) server and allow people to
use that for uploading photos without a clunky web interface. Bulk
uploads are _far_ easier using SFTP than via web interfaces, and
photos are often uploaded in large numbers. Heck that's probably
why those API applications get used instead of the Imgur website
in the first place. Use SFTP and you've got lots of wonderfully
easy to use FTP clients available already. Just write a script that
post-processes them for displaying in HTML after they've been
uploaded. HTTP is the wrong route from the get-go, if you ask me.

--
__ __
#_ < |\| |< _#

John

2023-06-29 01:49:00 UTC

The people sending you the links were screwing up, then. What you do is
upload the image, then right-click the image on the resulting page and
copy the image link. No JS, it's just a JPG.

Post by John
Is anyone aware of open-source servers which implement an
Imgur-compatible API, or of efforts to define a "standard" set of
endpoints for image uploading and retrieval?

If a variety of different self-hosted options accept POST requests to
/imageapi/upload, then it's easy to use them interchangeably. That's the
advantage of a standard API.

Post by Computer Nerd Kev
A quick search suggests that Imgur use OAuth 2 in the API for
restricting API access, so that's just for their own benefit.
Even better, set up an SFTP (FTPS, FTP) server and allow people to
use that for uploading photos without a clunky web interface. Bulk
uploads are _far_ easier using SFTP than via web interfaces, and
photos are often uploaded in large numbers. Heck that's probably
why those API applications get used instead of the Imgur website
in the first place. Use SFTP and you've got lots of wonderfully
easy to use FTP clients available already. Just write a script that
post-processes them for displaying in HTML after they've been
uploaded. HTTP is the wrong route from the get-go, if you ask me.

The reason you use HTTP is because basically every device can access
it. Damn near every firewall lets port 443 out. I love non-HTTP
protocols on a philosophical level, but I don't suggest "oh well
obviously the best way to let my mom share a picture is to have her
mount a 9P filesystem via FUSE..."

If there's a common/standard way to throw images at a backend service,
that means you can interface with it via curl, via a little HTML+JS
application you hack up, or from basically any program written in any
application which supports HTTP.

john

Computer Nerd Kev

2023-06-29 03:20:24 UTC

The people sending you the links were screwing up, then. What you do is
upload the image, then right-click the image on the resulting page and
copy the image link. No JS, it's just a JPG.

Ah, great! I see that sometimes simply adding ".jpg" to the end of
an Imgur link is enough to get past the usual "please enable JS to
make Imgur work" barrier. I never thought it might be that easy.

Post by John
Is anyone aware of open-source servers which implement an
Imgur-compatible API, or of efforts to define a "standard" set of
endpoints for image uploading and retrieval?

If a variety of different self-hosted options accept POST requests to
/imageapi/upload, then it's easy to use them interchangeably. That's the
advantage of a standard API.

Making it Imgur-compatible strikes me as having little benefit.
Existing programs will be hard-coded to use imgur.com, so they
won't work as-is, and yet when Imgur change their API on a whim,
your site/s have to change as well to stay compatible.

I guess the only way it might work is if you plan to play tricks
with what the imgur.com domain resolves to. On Linux you might
be able to get the image uploader program to use a different
network namespace with its own hosts file pointing imgur.com to
somewhere else.

Post by Computer Nerd Kev
Even better, set up an SFTP (FTPS, FTP) server and allow people to
use that for uploading photos without a clunky web interface. Bulk
uploads are _far_ easier using SFTP than via web interfaces, and
photos are often uploaded in large numbers. Heck that's probably
why those API applications get used instead of the Imgur website
in the first place. Use SFTP and you've got lots of wonderfully
easy to use FTP clients available already. Just write a script that
post-processes them for displaying in HTML after they've been
uploaded. HTTP is the wrong route from the get-go, if you ask me.

The reason you use HTTP is because basically every device can access
it. Damn near every firewall lets port 443 out. I love non-HTTP
protocols on a philosophical level, but I don't suggest "oh well
obviously the best way to let my mom share a picture is to have her
mount a 9P filesystem via FUSE..."
If there's a common/standard way to throw images at a backend service,
that means you can interface with it via curl, via a little HTML+JS
application you hack up, or from basically any program written in any
application which supports HTTP.

My experience with hacking up over-complicated, semi-documented,
HTTPS APIs with Curl is that many hours and error messages could be
saved had an FTP-like protocol been used instead. Of course there's
no reason why using one protocol excludes also offering the other.

--
__ __
#_ < |\| |< _#

Ivan Shmakov

2023-06-29 08:12:09 UTC

I mostly ignore Imgur URIs that I encounter. If it took no effort
to upload, I'm not going to spend effort to view it, either.
(Though I understand there're cases when the effort is spend
elsewhere.)

More to the point, are "self-hosting" and the likes of Imgur
really the only available options? Because so far I can tell,
for something /you/ author there's at least Wikimedia sites.

FWIW, I've shared my share of images via Commons, and I have
a few small (and somewhat outdated by this point) Debian howtos
published on Wikibooks:

http://commons.wikimedia.org/wiki/Special:ListFiles/Ivan_Shmakov
http://ru.wikibooks.org/wiki/?curid=13007

There're practical considerations that limit my participation
on Wikimedia, but as a rule, I prefer a collaborative environment,
where my mistakes can be fixed without my direct involvement.

Then there're the likes of SDF, http://sdf.org/?join .

Post by John
If a variety of different self-hosted options accept POST requests
to /imageapi/upload, then it's easy to use them interchangeably.
That's the advantage of a standard API.
If there's a common/standard way to throw images at a backend service,
that means you can interface with it via curl, via a little HTML+JS
application you hack up, or from basically any program written in any
application which supports HTTP.

Very much seconded, both points.

But perhaps rather than reimplementing the (apparently complex)
Imgur API, it'd make sense to bug the developers of the applications
that support Imgur out-of-box to add support for http://ttm.sh/
and http://transfer.sh/ as well?

And while my Ecmascript / Javascript skills are nothing to brag
about, I understand that at this point, if I want to write an
application for an average Joe to use, Javascript is my best
bet by far. (And I'd be rather disinclined to try implementing
FTPS there.)

Even though my own programming language preferences (HTTP API
or not) lie elsewhere. Consider, e. g.:

http://am-1.org/~ivan/src/examples-2022/webwatch.mk

--
FSF associate member #7257 np. Wrecking Ball by Tiny Little Blackouts

Eli the Bearded

2023-07-03 01:47:52 UTC