Probably not, but we could shorten to image://sha1.png quite easily, which helps
1 Like
I’s say, it worth to use term “random bit length” instead of “algorythm”, because any good hash function will be ok. Usually, 128 bits should be ok, but very big hostings (like “yandex photos”) switched to 512 bits. Also, timestamp can be used to reduce random part (see mongodb algorythm for ObjectID).
Another way to save ~25% is use of base58 encoding or similar (base64 is not url-friendly).
Quick estimate: 128 bits + base64 => 128/6 => 22 characters.
4 Likes
That is correct, base64 encoding of 128 bits GUID should produce 22 chars:
7v26IM9P2kmVepd7ZxuXyQ
You can do ASCII85 encoding to achieve 20 bytes but the characters used are no longer filesystem friendly and that does not seem worth the additonal pain:
[Rb*hlkkXVW+q4s(YSF0
Compare with what we currently have @sam …
e76d2a89947069f0ce624d5989fa20c47a13d383
7v26IM9P2kmVepd7ZxuXyQ
… quite the difference, we could lop off 16 chars there.
2 Likes
So far, only @sam’s image://sha1.png sounds good to me. And I don’t feel any strong love for that. Why do you care how clean or ugly a filename a user doesn’t have to type in themselves is?
All the other ideas seem like more complexity for little gain. The whole idea of using a hash is that identical uploads can easily be optimized for disk space. Changing to some other ID doesn’t achieve that. You could store and save the SHA1 in the background and give out the same GUID for it, but there’s that complexity.
(And using MD5 is bad since there’s a non-zero chance someone will want to post deliberate collisions. But as easily forced SHA1 collisions will probably be upon us soon, too, maybe the complexity would be good?)
1 Like
I think the encoding difference is pretty obvious, it’s almost 2x as large using hex encoding vs. base64 encoding, for the same 128-bit GUID.
1 Like
Google Photos also switched to base64 (?) encoding some time ago for shared photos… Shorter URLs, but still as secure as the long ones.
6 Likes
I know the technical reasons so I’m not expecting an easy solution, but I do find it sad that in such forward-looking software as Discourse, computerese like this is visible to the user at all.
vs.
is neither here nor there, really.
It is 80% file name though. So that is the reality. Count the chars!
The hostname is 41 chars, and the image ID 40 chars in the first example. The full URL from // to .png is 104 chars. I bet you could shorten that URL a lot with a suitable CNAME. Register a WX.YZ host and assign two or three character labels there:
//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/
//dm.cd.cs/
44 versus 11.
(Of course, Czechoslovakia doesn’t register hostnames anymore.)
I already mentioned I can make image:// work 
4 Likes
is 134 characters, of which
//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/e/7/e76d2a89947069f0ce624d5989fa20c47a13d383.png
is a whopping 105 characters. That means 78.3% of the string is the filename 
Without the filename altogether, the markup is
![fat-city-apple-ii|690x473]()
with the smallest possible URL path it would be 78 characters
which is a reduction of 57% in size!
That assumes, however, that:
- we can map to a tiny 2-char domain
dm.cd.cs - we can use
oinstead oforiginalin the path - we can switch to base64 encoding instead of hex encoding for the GUID in the filename
cc @zogstrip
1 Like
image://3/7v26IM9P2kmVepd7ZxuXyQ3.png
works without any changes to storage, and a fairly straight forward change to the md pipeline
No magic domains needed.
10 Likes
Nice, let’s make that so when you are back, then! 
vs
6 Likes
@sam is working on this now so we should be able to get
image://vaLFE+HaBPe06ZIwhR6iqv64zE4.png
vs
//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/d/8/d813b1138aa816ad87eeeebf55af33ebf3c66cf0.png
which I, at least, view as a substantial quality of life improvement for day to day image handling in posts.
(note that we’ll need to use base62, to avoid the / and + chars in URLs though)
6 Likes
Just use URL-safe base64 - uses - for 62 and _ for 63. https://tools.ietf.org/html/rfc4648#section-5 base64 - GoDoc
3 Likes
Cool up to @sam how he wants to handle it, then. Not a huge fan of - and _ both (potentially) being in URLs though.
This is now implemented, I opted for base62 cause it is super friendly on the eyes. I could have allowed $ and * or some other stuff in the URL to shorten it some more and bring it up to base64 but honestly I feel base62 is good enough ™
13 Likes
