Show HN: Memlink, a self-contained web page in a link (opens in new tab)

Haha thanks for posting this! It is a custom templating syntax I came up with to store the document data as compact as possible before encoding.

You have:

<doc_config> | <block_data>

Where doc config is:

<palette_index> ; <background_index>

And block data is a list of blocks separated by | that have the following structure:

<block_type> : <block_value> ; <block_config>

And block_config is an additional set of characters separated by semicolon. Right now each block reads its metadata differently, so the order of the metadata options depends on the block they’re used for. I’d like to standardize them eventually. Most start with:

<background_color_index> ; <text_color_index>

The color indexes map to the index position of the given document palette selected. Every palette’s first two colors are white, and black.

Probably could make this shorter by applying compression optimized for text. Also I wonder what happens if you enter | into the custom text field, can user input break this or will the special characters be escaped / handled some way?

Great point - no privacy policy yet (have spent only a handful of hours on this PoC so far). I hope to get around the server-data issue like you mentioned with the hashbang suggestion from another commenter.

For the record, I am completely ignoring the path server-side, and just proxying the request via nginx to a single page Next.js client that is completely client-side rendered. The server doesn’t need the path at all, so yes I do hope to avoid sending it altogether. Going to try to implement that update this weekend without breaking backwards compatibility with already live links.

A simple way around this is to store the data in the fragment, and do the parsing from that.

That’s a neat idea, I’m gonna have to play around with that! Thanks for the tip.

I’d imagine the length issue would become much more of a problem sooner, and any interactivity via JS will add to the size of the link considerably. The benefit of the block mapping is you can house relatively complex components behind a simple string map without adding that bloat to the url itself.

The idea is that once you have the renderer - whether it’s the hosted site, a native app packaging similar to a “browser” of sorts - you could load and view any Memlink page entirely clientside. The current app is a static html/JS SPA sitting on a small VPS and only handles serving the initial renderer code if not cached locally already.

Thanks for checking it out!

I need to add some syntax docs, but ideally I want to abstract out the syntax for an easier-to-use form based block config so you know how to use the block.

For the image tag, it currently takes three options:

<img-style> ; <img-size> ; <justify-content>

img-style can be: "r" for rounded, or "s" for square (for some reason square isn't working right now, need to check on that...)

img-size can be: "xs" for x-small, "s" for small, "m" for medium, "l" for large and "f" for full-width

and justify-content can be : 's' for flex-start, 'c' for center, and 'e' for flex-end. The image is wrapped in a flex box that uses this setting to justify the image.

In writing this comment I just realized I missed the bg-color config for the image block! :D Going to add that.

Here's your updated page: https://meml.ink/MTs1fGgxOkp1c3RpbiUyNTIwR2Fycmlzb24ncyUyNTI...

Hope this helps!

My two favorite are:

- the Tweet block, you can just pass it a tweet ID and it's options are <bg-color>;<alignment> where alignment is 'l', 'r', or 'c' for left, right and center respectively

- the ASCII text block which uses figlet under the hood. Right now it only takes <bg-color> ; <text-color> but I want to also expose different figlet fonts you could set.

Also just noticed your links got stripped. I was seeing that issue with decoding the ":" in the URL, but thought I had pushed a bug fix for that yesterday...going to investigate that more. Really appreciate you using it, the best of feedback and learning :)

Edit: I wasn't able to replicate the stripping issue on my end when I updated the link, so maybe there was a cached version that you got from before I pushed the fix - if you don't mind please trying a hard refresh on your end and giving the link another go, if you choose to use it again! Thank you.

Update: this is now live! If you navigate to a legacy path w/o a #, it will redirect you on load to the new router protected by the #. This was a great idea for privacy, and I really appreciated this feedback.

Please give it a go and let me know if it works for you, if you get the chance. Thanks!

That’s a great idea! I’m gonna try working that in. Thank you for checking it out.

Nice, yeah! Cool app :) I make my own beats from time to time and will give a try for my next drum line jam. Neat you packed all that into the url!

Wow yeah very similar, thanks for sharing! I’ll have to dive into this. This person was way ahead of me having done this 8 years ago, I wonder how things have changed in that time and what they would change today. The vision they share seems very much inline with my perspective - unique, instantly shareable bite-sized content with zero associated storage cost. Great for usage in tweets, social media, internal communication, etc.

A page within a page, huh? Getting fancy. I haven’t figured out a good way to solve this concept. It works better if you make the page and then use a url shortener to refer to that page, so you don’t have the entire contents of the sub page in the first page :D fun stuff! Any ideas? Thanks for trying it out.

Very similar, but I love that name! Itty bitty indeed.

Oh nice yeah, seen a handful of very similar projects posted. This one you shared has a rich editor experience! I like that - thank you for sharing.

Yeah the encoded param is regenerated on any block change, so you’ll know if there’s a change. I’ve been thinking of ways to lock down content. Maybe a separate hashed entity in the document config that is only able to be decoded with a localStorage key on the client that authored the content. Thanks for your input!

Yeah, so sorry about that, it does suck.

It’s only for “legacy”[1] links that aren’t using the hashbang for privacy, the page will redirect to the hashbang. This causes the back button loop. If you create a new page or link to a new link, this shouldn’t occur anymore. Since the link has the page, and I posted this before I added the hashbangs, it will always have this issue unfortunately. C’est la vie - thanks for the feedback there.

[1] The project is less than a week old and there are already legacy concepts that need maintaining, that’s a first for me.

That’s a cool one too, thanks for sharing - hadn’t seen it before.

I think biggest difference is the drag and drop block-based authoring experience of Memlink. Looks like that author has an additional cool project called link-lock to provide protected links - going to look more into it.

Thank you :) You made my day with your kind words.

Hey thanks for breaking it! :) the templating lang is definitely brittle right now and will need to be revamped for anything close to real usage.

I managed to add emoji support last night, which ended up increasing my encoded payload size by about 30%.

I need to add some debouncing to the block updates as it’s real time right now but with all of the encoding seems to overwhelm the page if you type too fast.