imgur / image-upload API specs

[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.

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!

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? Seems like it ought to be
an RFC or something but maybe that's a little out of their scope.

john

[Computer Nerd Kev]

In comp.misc John <jo...@building-m.simplistic-anti-spam-measure.net> wrote:
> 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.

> 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?

> 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]

n...@telling.you.invalid (Computer Nerd Kev) writes:

> In comp.misc John <jo...@building-m.simplistic-anti-spam-measure.net> wrote:
>> 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.
>

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.

>> 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!

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.

> 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]

In comp.misc John <jo...@building-m.simplistic-anti-spam-measure.net> wrote:
> n...@telling.you.invalid (Computer Nerd Kev) writes:
>
>> In comp.misc John <jo...@building-m.simplistic-anti-spam-measure.net> wrote:
>>> 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.
>>
> 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.

>>> 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!
>
> 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.

>> 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]

>>>>> John <jo...@building-m.simplistic-anti-spam-measure.net> wrote:
>>>>> n...@telling.you.invalid (Computer Nerd Kev) writes:
>>>>> John <jo...@building-m.simplistic-anti-spam-measure.net> wrote:

>>> 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.

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 .

> 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]

In comp.infosystems.www.misc,

John <jo...@building-m.simplistic-anti-spam-measure.net> wrote:
> 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? Seems like it ought to be
> an RFC or something but maybe that's a little out of their scope.

Chevereto seems to be a self-hosted Imgur clone. They'll try to steer
you towards paid hosting by them, but I understand there's an open
source version.

https://chevereto.com/

Versions 3 and 4 there, but he wants you to buy them (not rent via
subscription). There are free versions but they are getting hard to
find:

https://github.com/tanmng/docker-chevereto
https://github.com/rodber/chevereto-free

Chevereto focuses on easy uploading, easy sharing. It doesn't do tags
and has limited searching. I found a free site suitable for demo
test/run:

https://jpg.church/

(It redirects to jpg.pet today, but the backed is still jpg.church.
JPG(Pet|Church) doesn't seem to have email, so you can sign up with a bogus
address, such as foo...@jpg.church / fishysite)

Elijah
------
has not looked at the API of Chevereto