The first one is correct, I never thought about data compression at all until 3 days ago where I had a lot of JSON to store. The best Javascript compression implementation I could find by Googleing around was lzw, which due to the way it steps through the data and builds the dictionary is inherently inefficient, never mind that it compresses to an array which can only be stored as far as I know as text delineated by commas which tends to increase size. So I wrote one that analyzes and prioritizes the dictionary before applying compression, and doesn't need a dictionary to be predefined like lzw does, which is necessary for one of my use cases.
I wasn't going for "I'm a compression expert", I was just going for "Look at my latest weekend project" and "here's a code sample."
The decision to name it after me was a hard one, but I figured namespacing my projects would prevent me from using up all the good ones.
I should also emphasize that I have no idea if this particular algorithm already exists somewhere, I've only looked at a few compression schemes. Didn't mean to invent, just wanted to solve my particular JSON problem with client-side compression and get data smaller than I could achieve with existing libraries.
Also, be aware that many non-expert attempts to develop compression algorithms turn out to be flawed. However, it sounds like you've developed a compression pre-processor specifically targeting JSON-like structures, which seems like a much more plausible accomplishment than a non-expert developing a brand new general-purpose compression algorithm that can beat LZW.
All that said, if I were considering hiring you I would be much more interested in your ability to rigorously analyze the strengths and limitations of your algorithm (rather than the algorithm itself). Plus, without that rigorous analysis it makes it much more difficult for me to judge the quality of your algorithm.