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. RFC 4648 - The Base16, Base32, and Base64 Data Encodings base64 package - encoding/base64 - Go Packages
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
