Hacker News Reader

Here is it decoded:

{"interval":"week","periodicity":1,"timeUnit":null,"candleWidth":4.3486590038314175,"flipped":false,"volumeUnderlay":true,"adj":true,"crosshair":true,"chartType":"line","extended":false,"marketSessions":{},"aggregationType":"ohlc","chartScale":"linear","studies":{" vol undr ":{"type":"vol undr","inputs":{"id":" vol undr ","display":" vol undr "},"outputs":{"Up Volume":"#00b061","Down Volume":"#ff333a"},"panel":"chart","parameters":{"widthFactor":0.45,"chartName":"chart"}}},"panels":{"chart":{"percent":1,"display":"F","chartName":"chart","index":0,"yAxis":{"name":"chart","position":null},"yaxisLHS":[],"yaxisRHS":["chart"," vol undr "]}},"setSpan":{"multiplier":5,"base":"year","periodicity":{"period":1,"interval":"week"}},"lineWidth":2,"stripedBackground":true,"events":true,"color":"#0081f2","stripedBackgroud":true,"eventMap":{"corporate":{"divs":true,"splits":true},"sigDev":{}},"customRange":null,"symbols":[{"symbol":"F","symbolObject":{"symbol":"F","quoteType":"EQUITY","exchangeTimeZone":"America/New_York"},"periodicity":1,"interval":"week","timeUnit":null,"setSpan":{"multiplier":5,"base":"year","periodicity":{"period":1,"interval":"week"}}}]}

I bet if they were more aggressive in using defaults it would be a lot smaller.

OT, we used to joke about LISP source code contains mostly brackets. Nowadays we literally store, transform and pass around willy nillily

Speaking about LISP and state in the URL, this is how OVH stores the state when you buy a domain from them:

    https://www.ovh.com/fr/order/webcloud/?#/webCloud/domain/options?selection=~(domains~(list~(~(name~'somethinghn.com))~options~(~'dnssec)))

That's Clojure's EDN encoded for ClojureScript isn't it? I recognize this syntax from briefly working on a CLJ/CLJS app.

Nope, edn uses square brackets and doesn't have a `list` keyword. This is some custom representation.

Probably written in Common Lisp? Based on some quick searching I found this reference https://docs.ovh.com/us/en/web-paas/languages-lisp/

Or it could just be that s expressions are easy to parse.

we used to joke about LISP source code contains mostly brackets.

There was a programming language in the 1970's called SAM76 that didn't care how many closing parentheses you had, as long as it was more than the number of opening parentheses.

So, something like this was perfectly valid:

  a(1+r(em(2)))))))))))))))))))

Relevant xkcd: https://xkcd.com/859

That's genious IMO. Making sure the amount of opening and closing parantheses is equal is annoying and unnecesary.

It screams "trust me all good with the closing parantheses".

I disagree. I would say when I get an unbalanced paren compiler error, it's more common for the omission to not be at the end of the line. Having the compiler silently swallow the error would lead to serious bugs very quickly.

    if ((v1.x()-v2.x())*(v1.x()-v2.x())+(v1.y()-v2.y())*(v1.y())-v2.y())+(v1.z()-v2.z())*(v1.z()-v2.z()) > distance*distance) {
        // collision
    }

Would you like this to fail to compile? Or would you prefer it to silently return the wrong value?

I'd prefer the compiler file an HR complaint against the author.

if collisioncheck(v1,v2, distance) { // collision }

where you have defined an actually readable equivalent inside of collisioncheck would be my prerogative... I also agree paren matching failures should error, but your example is NOT why.

What if I wanted to copy that expression and use is as part of a different expression?

Interactive prompts already do that. Eg if you google "2+2)*3" it will correctly print "12". This effectively lets you append operations to an expression without editing both sides.

On the other hand, auto closing parentheses in code is a terrible idea for obvious reasons. There are only like 7 languages used in industry and they all have excellent tooling that integrates with your editor to eliminate issues like this.

paredit and rainbow parens makes it a non-issue for me.

I found that joke funny until I realized that, if you sum the count of round, square, angle and curly braces together, your typical piece of C++ or Java code has more brackets than equivalent piece of Lisp code...

Right, but having them all be the same is what people are joking about :) Although I might check the lisp/clojure vs java code on techempower or another rosetta stone like example.

That, and the usual style of stacking all closing parentheses together at the end of the last line of a sub-expression / statement / whatever. People sometimes do this in Java and it's just as unreadable.

You read it by indentation not by counting parentheses.

It's still very easy to make mistakes reading it that way. If you are reading it by indentation anyway you may as well use a parser that closes parentheses for you at indentation changes. (Like the ML family and Haskell and Python all decided to do.)

I don't find reading properly indented Lisp any harder than reading properly indented Python. I agree however with respect to having the tooling help with balancing delimiters, although I let the editor do that job instead of the parser. And that's one of the major advantages of Lisp. Structural editing is considerably easier to implement. Parinfer[1] for example is really cool. I have to say I'm really excited about tree-sitter allowing similar structural editing for harder to parse languages.

[1] https://shaunlebron.github.io/parinfer/

Well yeah that's a major reason why most programmers hate LISP syntax. It uses a parentheses for everything even though every keyboard has round, square, angle and curly braces.

I somehow doubt it. I tutored quite a few people of all ages who started to learn programming, mostly C, C++ and Java - they all initially have been mostly confused by the different kinds of brackets. They quickly understood where the brackets go (scopes/blocks, function calls, array declarations and access, etc.), but took some time to internalize which bracket type is used in which context.

I suspect the main reason programmers dislike Lisp syntax is that they try or see an example of some basic arithmetics, get surprised by the prefix notation that's so "unnatural" compared to the "obvious" infix notation they learned in primary school, and write off the entire language as weird, not noticing the fact that infix math is an exception in programming languages, as otherwise almost all code they write in any other language is in prefix notation too, just with a parenthesis shifted to the left.

A somewhat mind-blowing observation to some people:

  (foo (bar baz quux))
  
  foo(bar(baz, quux));

The two lines above are both in prefix notation. You can go from the first to the second one by a) shifting each left paren by one token to the right, and b) adding commas between whitespace-separated tokens.

I suppose beginner programmers might find all the different kinds of brackets in C++ confusing but after some experience, it helps a lot with readability. If I see `a[1]` then I know that `a` is probably an array. If I see `a(1)` then I know that `a` is probably a function. You could make the argument that those are terrible names for variables and methods and you'd be correct, but every small bit of context helps.

Like most of the verbosity in those languages it benefits the reader more than the writer.

Clojure uses [] and {}, eg. :

  (defn fib [x, n]
    (if (< (count x) n) 
      (fib (conj x (+ (last x) (nth x (- (count x) 2)))) n)
      x))

I suspect it's probably a global library that handles this. So refactoring it in one place would be difficult. If I had to guess their implementation looks something like this.

SomeUrlService.pushState(JSON.stringify({ foo: 'bar' }));

SomeUrlService.navigate('/some/url/here')

Likely, that "SomeUrlService" is also tacking on plenty of other shit to the URL that is passed along. I don't work for Yahoo and never have, so this is all pure speculation.

Having worked there years and years ago, I doubt it. All those parameters look like chart parameters to me, probably local to Y! Finance.

What is the point of the encoding ? Is it obfuscation for the common user ? What's wrong with http:// url.com/api/?interval=week&periodicity=1... since the encoded version is not shorter.

Encoding isn't usually to obscure but to allow using characters not allowed in a URL or wherever text is being stored. This makes it a bit easier to directly take that encoded text later and decode it into something like json.

That makes sense, thank you

> What is the point of the encoding ?

Absence of special characters. No need to escape symbols like {}:/\?& etc, etc.

They have a nested structure, it's a pain to encode that in query parameters.

> https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6...

Dear god... this link was real. I thought it was like a joke or something

Genuinely curious to hear why you are so shocked. Long, ugly, user unfriendly urls are really prevalent. Arguments can be made even query params are pretty ugly.. Are urls expected to be a good UX these days? What's the big deal?

Just because a thing is prevalent doesn't mean it's good. I have a hard time believing all those parameters are completely necessary for the amount of data being displayed. Often times it feels like people just base64encode(page.state) and call it a day.

I think it's advantageous to keep the complexity and specificity of information in URLs to a minimum outside of what's needed to retrieve the data set as it can make backwards compatibility easier - it is valuable (for long lasting tools) to have URLs that users can favorite and share for their common searches.

> Just because a thing is prevalent doesn't mean it's good.

I agree with this sentiment. I'm not sure I've ever seen a url referred to as "good", I was just a bit confused as to why someone would baulk at a URL. In my opinion everything after the host portion of the url is to serve the apps needs, so it knows where to go or what to do, it's not really an interface for the user as obviously there are better ways to present that.

I’d say everything after the host is part of the UX, and should serve the user needs. For example:

* Should be book-markable.

* If searching with a query, should have a clear query parameter for ease of browser integration.

* If the URL contains slash dividers that can be read as categories (e.g. storefront.com/department/category/product), then deleting everything after a given slash should go to that category’s page.

* The link should be short enough to be sent over a plain-text conversation without becoming a wall of text.

* The link should be short enough that it cannot hide a malicious subdomain (e.g. Google.com.flights.malicio.us/more/elements).

* I should be able to guess if you're sending me a link about composting or a Rick Astley video

Opaque slugs are problematic in a low-trust world. Phishing attempts are easier when the parameters are indecipherable. I'm not clicking on that shit in a text message or an email. I've seen what happens to people when they do.

Eh, I mean URL shorteners are a thing and all kind of things redirect on the web. The length of the URL doesn't really tell you much.

URL shorteners are a menace. I'm not clicking on the link if you send me a shortened one, especially not when on mobile. These days, shortened links have two primary applications: forcing you to go through a tracking/analytics gate, and serving single-click exploits. Neither of those is serving the user (unless you read it in "To Serve Man" sense).

No - but they have been referred to as "cool" before. Gotta love the early 90's.

https://www.w3.org/Provider/Style/URI

The point of a URL is that I can copy+paste it into IRC so my friends can look at the thing I want to share with them.

If the URL has a bunch of goop in it, people are going to make fun of me for it, especially if it's super long and doesn't fit in a single line. Or if there's stuff in there that's specific to me and not the thing I want to show them.

Where I work, we consider URLs part of the UI. Users should be able to share links with each other without pasting a wall of text. We also try to make all URLs human parsable so that they know what they are sharing.

I can say that many, many times, I have zoomed in, picked date ranges, added options, then pasted the yahoo finance url to others... and they have all those same configs passed.

It's awesome and incredibly handy.

Yahoo is on the ball here.

Agreed. However they could still simplify the urls a ton by including only non-default parameters, and still achieve the same thing.

Everything in chart is customizable, so no, its not possible to achieve the same thing in the way you are saying

Yes, but anything that hasn't been customized doesn't need to be included in the URL, so most URLs will be much shorter by only including non-default values.

And what problem does this solve? Hint, it doesn't. Long URL is ugly but who cares. Life is too short. Nice or ugly is relative. It stops nobody from using the tool or sharing links. It's a non-problem really.

I don't think people care so much about a messy address bar as a messy chat/email message after pasting a URL. Shorteners and vanity URLs exist, but that's more friction than just copying from the address bar as-is.

This can be overcome with html, markdown, and other rich text formats that let you specify the visible link text (missing from many chat apps*), but that's also friction to compose compared to automatically linking from just a URL.

*Slack's implementation is awesome: type the link text, highlight it, and paste a URL.

> I don't think people care so much about a messy address bar as a messy chat/email message after pasting a URL.

But it's painful how few care about that!

I always clean them up before I send them (just manually - typically meaning all query parameters, e.g. with Amazon the text description after the actual ID) rarely even feel the need to check they still work, it's pretty easy, but maybe I shouldn't bother because it's only me that cares; they don't seem to notice that their links occupy half the screen and my don't!

It's not even only about messiness. "https://news.ycombinator.com/item?id=34315441" isn't some horrible long base64, but it's not a good UX either: when you paste it in a messenger, or in your notes, by default the reader can't tell what's it about without clicking.

> *Slack's implementation is awesome: type the link text, highlight it, and paste a URL.

Yes! Matches my vision of hypertext perfectly: I usually type a message in normal human language and then paste links all over it for the reader who needs to dig deeper.

> by default the reader can't tell what's it about without clicking.

Most chat apps like Discord will automatically include an embed generated from a URL's metadata when present in a message.

At least in Telegram, this works for at most one link per message, and quickly fills the screen if you send multiple such messages.

And I believe that there is no standard API to get previews of non-public websites in a work chat, you need to develop site-specific bots or something like that?

> previews of non-public websites

It would be interesting if browsers / OSes / apps offered a way to use the browser's cookie jar / basic auth headers / whatever sessioning scheme in whatever apps the user decides should display authenticated previews. Ask the user to allow the release of browser data scoped to the domains that the app suggests. Similar to how some Android apps can put up a prompt to release a Chrome-saved password to an app (which I really wish more apps would include).

Examples of why this is bad:

* http://example.com/settings/transferownership?to=efreak * http://example.com/settings/deleteaccount?confirm=true * http://example.com/sendmoney?to=efreak&amount=10000

Might need a redirect. Do previews follow redirects? Does your poorly-written chat app filter urls by protocol, or does it just look for a token with '://'? A good app will allow me to link to things like steam://connect/IP so I can invite you to a game.

* tel:9005555555 (call a phone number. Fortunately, this requires confirmation these days, but what if you're on desktop or the app that does texting can directly make calls without invoking the dialer?) * steam://exitsteam (steam will exit if it's running)

I just include a screenshot. It’s not that hard.

Plesse no

There is a standard for this. It's called oEmbed: https://oembed.com/

The chat host still likely needs access to the "non-public website" to discover and call its oEmbed API, so that's something you'd have to figure out, but any website anywhere can offer oEmbed metadata if it wishes.

> Are urls expected to be a good UX these days? What's the big deal?

I think they are. If I want to go back to some page I was looking at earlier, it's really nice to be able to find that page in my history. That Yahoo URL is going to be hard to differentiate if you looked at a few stocks.

It's also handy if the URL's are predictable enough that I can hit one directly rather than having to go through search. Good for me because I don't wait on page load, good for them because they don't have to serve my search request.

It's pretty low on my list of UX annoyances, but it is there.

Pipe that into bash (ie: the user doesn’t know if they’re loading malicious state)

I Just like to keep query params simple and readable. I understand the possible use case for this obfuscated url which would make it difficult to scrape the site

In your example, absolutely the first URL is better. But if as in the case of the OP, you're trying to encode an entire flowchart, I would argue it's a bit of a pointless exercise. Maybe you could come up with something reasonably readable, but I don't think anyone would care. It really depends on what kind of state you need to store.

Whoever needs to copy that long intestine of a url definitely cares.

If you can shorten the URL, sure. But if data stored in the URL means it needs to be incredibly long, I don't think most users care whether it's readable or not. Of course, at a certain length, it's worth reconsidering whether storing all the data in the URL is a good idea.

A flowchart can be encoded as simply the name of the state you're currently in.

How do you know what all the other states in the chart are and how they are connected?

How would you predefine a state to include the flowchart nodes that the user creates?

I decoded that, gzipped --best, then re-encoded and got something that's shorter at least

H4sIAAAAAAACA7VU3W7TMBS+5ykmcxuNdOlGyd3QmECCIdYWNKYKnSanqVfHNrbTNqoq7QF4Sp6EYyfpaMYtdz7H5/vOz3fsHePSoVmDYCnbIK5YxDQarnKecVezdBAxx0ucSu5YKishIpaBzAV+47lbsnR4mgxHF+dv4jgZJYPh4PV5xBaCa405SxcgLEZsrUTlKXI0AojTmYq8kD90x8woa5fAzcGxBOMmtUaqSnCJVBVuHRLDE2sJZoVujNZyJS1Ld3viLAqDBTjytGi1FBlrCccZiI4RDHmtq3KOHst+P/6iMk8qmRs6eo9rCDovhXOpKxeiOZXRh0Qs51aHBvtXVJmqXAee6pOvYSIU+DKO5/HFgMBXaiP/8i8WSZKAR2qQ6NUJLXh5wECJJFog23gZriFzioYXnw7P215vIPA0oP2+4wmYxkkHUjpD6YLKT8Vfs39x+PZz3FKSiNWXWx6Y5HGEVpb72TebQjlroMCP78csvZ+11m2wDpDepGa+UkuyUrU+QVkJx7XgSN1Ra3OwPl/dyHe0qLvWDM30l9qzetXbpT3z0htOO/oWslVhFKXvVg/XNBF7WEQl/GC9TqPB4ow9Ax7jPoEOA1ZGKwMOvZHz9YGORsw7ct8oL65w7VeXjKyyTpW3IAvsXpqty7nymt3v2nMrT2N8nj9gFoQ8uvxZKYft+r/7Mv0wuQvPhyZO1BN6zN+V9HeXJQ0sg1c3uPlxp8wqLFvv7T//Hfq/wf8Qaz/bv/gDbvc6N5oEAAA=

you could come up with a better compression scheme given that the dict keys and many of the values are probably common across everyone even if they don't repeat multiple times for a given user. a lot of flexibility would be lost though, and you would need to always update the scheme in a backwards-compatible way.

Once you've already given up on human-readability, it probably doesn't much matter how long/gross the result is. Rather than spending effort and adding complexity, just provide a built in URL shortener.

Isn't storing state in urls and then using a url shortener just a key/value store with extra steps?

But with added session id energy too!

True, though I think the differences around shareability matter— a mapping-table entry is immutable, whereas even a non-logged-in session token is probably not.

Well, there are limits to the lengths of URLs in much of the internet’s infrastructure, so better compression could still be useful.

This is the critical point to make. Paste a few long texts into the boxes and the url goes into the hundreds of thousands of characters long, whereas this says that anything more than about 2000 chars puts you into uncertain territory:

https://stackoverflow.com/questions/417142/what-is-the-maxim...

I agree, same reason people use json in the first place despite the inefficiency, it's easier.

Could start with a smaller encoding. Use single-length keys, or better yet use protocol buffers or even ASN1. That's similar to taking advantage of common key names.

would it be feasible to include the compression dictionary along w/ the data? And, maybe just send it once on the initial request and store it on the client?

> would it be feasible to include the compression dictionary along w/ the data

In theoretical terms (in particular Kolmogorov-complexity perspective), I believe the inclusion of a dictionary wouldn't help, it would strictly increase size. It can help (specially from a Shannon information perspective) if the compression is too computationally demanding to build the data model (which is kind of what all compressors do); but it almost certainly doesn't help in the case of something as small as an URL. But then it's possible to just pack a common compressor with the website (and just refer to it with a version code).

I think the web in general would benefit greatly from some kind of standard compression libraries. Compression tends to have a significant cold start cost to work well, if that were mitigated certainly something like an url could be far shorter.

I believe HTTP2 has header compression (RFC 7541)[1] with 'static tables', which seems to be a form of dictionary, but surprisingly to me no html compression with such shared dictionaries. There is caching libraries (unfortunately cross-domain caching seems to be deprecated[2] due to security concerns) I believe which helps in other ways, but I think a true dictionary-style compressor would bring huge bandwidth savings.

Major web entities should get together to develop those standard dictionaries (and which algorithms to use them with), so they are reasonably fair for everyone (maybe even language specific dictionaries should be used).

Security seems indeed a concern, but I think the key would be carefully preventing that a content were decoded with the incorrect dictionary (meaning the server could serve a different web page than the standard decompression) -- but overall it doesn't seem like a big issue (similar to cache, less problematic than cross-domain caching).

In the future maybe even one of those fancy neural network (or otherwise machine learning inspired) methods could be an option, specially useful for highly bandwidth constrained like rural or satellite internet (although of course performance is always a priority with mobile devices being major users).

[1] https://httpwg.org/specs/rfc7541.html#static.table.definitio...

[2] https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca... Is this still accurate?

> I believe HTTP2 has header compression (RFC 7541)[1] with 'static tables', which seems to be a form of dictionary, but surprisingly to me no html compression with such shared dictionaries.

To my understanding, that static table in HTTP2 is directly in context of recommending and discussing Brotli compression, which does use a table like that as a standard static dictionary in HTTP2+ scenarios including other static dictionary inclusions derived from a corpus of HTML documents.

https://en.wikipedia.org/wiki/Brotli

Thanks, I didn't know Brotli! Indeed it seems to include a dictionary in its compression which seems to help significantly with small pages. I hope compression continues to improve in this way.

> To my understanding, that static table in HTTP2 is directly in context of recommending and discussing Brotli compression

It seems separate, that would be a header compression for HTTP2 header itself, while Brotli encodes content (usually html, css or js).

The header compression in http2 has atypical requirements placed upon it: contents of different headers in a single request must not impact each other's compressed size[^], lest an attacker able to manipulate one of them can use that to guess the other. Thus, LZ77-style compression is out of the window, as well as using Huffman codes selected based on _all_ the header values. In essence, each header value (in a single request) has to be compressed independently. IIUC the dictionary you reference is used for header keys (as opposed to values).

[^] this statement is a bit of a lie for reasons of simplification

> would benefit greatly from some kind of standard compression libraries

Correction: standard compression dictionaries

The possible advantage of the encoding is that it that it can be encrypted and make parameter hacking impossible.

Would have to do the signing server-side, predicated on the server checking the entire state to ensure validity. Such effort being put into preventing parameter-hacking would suggest there are serious vulnerabilities in that website. The URL is meant to be modified by the client.

> The URL is meant to be modified by the client.

Clarification, the human user probably won't want to modify the URL, but the client will.

With something nice like the Google url, I would happily modify it myself.

Harder. Not impossible. Harder. I don't want to make it sound like I am being disagreeable just for the sake of being disagreeable. If there is one thing the past decade has shown, it is that hacking is just a matter of time and whether a determined person is willing to direct resources at it.

I see you, and raise you:

What if they encrypted the parameters with a one-time pad ?

Hmm. Most likely ( if not only ) way to counter that would be social hacking ( because I assume the pad is generated automatically from some source ), which seems like the best way to obtain it. Then again.. I am not an expert in this field ( but we do sometimes use parameters from link for some projects ). Is it refreshed after some time passes ( if so, maybe there is an easier way to just observe what changes )?

One-time pads have to be stored server-side. If you're going to do that, you might as well just store the data itself under a GUID server-side so you avoid network transfers and then put the GUID in the URL.

You don't need to encode it to do that though. You can just sign the URL

Yeah, why not just base64 encode, shove that into a db with a shorter key? I'm pretty positive this is how tiktok works for sharing videos.

Probably don't want to pay for space for unauthed users.

I think the other params are custom too. There's probably other state not being stored in that URL. If users want to send charts to each other and have them show up the same, this actually seems like a reasonable way to do it.

Another reason to not base64 encode is that many URLs with base64 strings will break in iMessage do to strings randomly matching various keywords that iMessage looks for. I think ‘usd’ is one such substring to look out for.

base64 does not have the problem here, iMessage has. Frustrating.

Agreed, iMessage should have URL detection that supersedes any other string parsing.

The fault doesn't lie in iMessage, it lies in Apple in general. Google's AOSP keyboard will IMMEDIATELY detect that you are writing a link when you'll put http(s):// in front of whatever else you're currently writing and will just shut up and let you finish without interrupting every 2 seconds with autocorrection suggestions. This does not happen on Apple's i(Pad/O)S keyboard, where typing a link will usually leave the user with an excercise in frustration, trying to fight over the autocorrection, which, for the 17th time, has decided to convert your URL into "normal words". Not even changing the keyboard seems to fix it, as, from what I remember, Gboard still uses Apple's prediction engine...

Curious if English is your mother tongue, and if so, which locale?

As a native speaker of en-US, I would write this as "base64 does not have the problem here, iMessage does."

Right before I was forked my parent did “export LC_ALL=C” and here I am.

Originally en-AU. I was trying to match the "have" with a "has". My sentence has a truncated " the problem" in my head.

Your version reads more correct, thanks for pointing it out.

Surely that's something that Apple should fix, rather than everyone else working around it?

Yes, but even if Apple fixes it, you still have to deal with old devices. Better have something that works everywhere rather than "this website is optimized for IE/Chrome".

This isn't at all comparable. It's purely an Apple problem.

In this case, its actually required. The state is actually for the entire chart. It has lots of settings not just the time duration but type of chart, crosshair should be set or not, then there are several types of chart studies which could be applied on chart along with their own settings. And also the chart drawings with their own settings. This feature is there so that people can share their own customized chart in full with others, and not a generalized chart.

Right no need to put it all in the URL, it could be just a random key pointing to local storage for instance, if not some cloud database.

If it points to local storage then it's not shareable.

If it points to a cloud database then you need a cloud database to do what a url could do.

Good point

I used to obsess over URLs as well, until the day I realised that there's no web page with the URL gmail.com!

Pass that super duper long Yahoo URL to Tinyurl and shrink it down to https://tinyurl.com/bdfepwar

It seems like storing state in the URL could benefit from URL shortening techniques so long as the secret sauce logic is both client and server side.

This loses all the benefits of storing all state in the url, which is that it's inspectable by the client. Using a URL shortener still makes all the data stored somewhere in the server

The primary benefit of storing all the state in the URL is that the server can be stateless. Using a shortener just moves the state to a different server. A user being able to inspect the state is just a side benefit.

Okay that's not exactly what I had in mind. My suggestion was to implement the same hash both server and client side so that the query string is small and manageable. Don't worry about the state not being fully legible because you will implement the hash decode on the client too. The code will be there for you to peruse.

How would you decode the hash? Amy of infinite states could map to the hash

I've lost my mind. I literally just implemented a dictionary web API the other week and have completely forgotten how I did it. Just forget what I wrote.

In a similar vein, I've long been a fan of Kayak's URL structure.[1]

[1]: https://www.kayak.com/flights/SEA-IND/2023-01-10/2023-01-14?...

I feel like you're ignoring the context of the linked post while also trotting out the most obvious comparison of all times.

ah, azure does the same for generating the "share" URL for their cost dashboards.

it additionally gzip's the data to compress it futher, with.. some savings..

in the above example you've shared, gzip would've,

  orig=1177
  base64=1572
  gzip(orig)|base64=768