Hermione Granger - muggle born with vested corporate interest
1,145 karma · joined January 6, 2017
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.
Linktree was definitely an inspiration to recreate - the big differentiator between Memlink and Linktree (and pretty much every other competitor in the space) is that, Linktree requires you to be connected to the internet. Once you've loaded Memlink once, for any page you visit first, you can load any new Memlink site entirely offline (granted, dynamic blocks like the Tweet block will show an offline state until you're back online). This is because the block parser and renderer is cached once you've loaded it, and Memlink operates as a PWA and can still render content without hitting a server. You can try it out on your end by:
1) Make sure you've gone to meml.ink at least once on your phone
2) Create a new site using Memlink on your laptop or desktop
3) Put your phone in airplane mode/disconnect from WiFi etc
4) Scan the Memlink QR code from your laptop/desktop onto your phone
5) The Memlink page should load fine on your offline phone
This could be hugely useful for a variety of reasons such as limited access to internet, limitations on bandwidth usage, resiliency for important documentation/info against network failures, censorship, last-mile connectivity, etc.
FYI this is now deployed and live, the privacy point was huge and I wanted to make it clear that this is CSR only, and the # was perfect. Now if you route to a legacy path i.e. without a #, you will be redirected to the memlink protected behind the #.
I will still work on a privacy policy that outlines these things :) Thank you again for the great feedback.
Please give it a go and let me know if it works for you, if you get the chance. Thanks!
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.
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.
Great xkcd nonetheless!
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.
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.
Normally I’d say the possibilities are endless! But I think they end right around 2000 chars :D
The key piece will be the parser module + block component set, which I plan to release as a standalone package, so any app could render these Memlink strings natively and easily.
Clearly though all the kinks are not worked out as others here have reported breaking it with some characters. Work in progress for sure!
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.
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.
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.
I’m planning on integrating with a url shortener service to shrink the urls by request in the editor, to address this issue.
Url shortener links still kinda look like spam though…
Another consideration is that they can be exported to QR code, or placed in links on other pages so you’re not ever really interacting with the full URL - like how you got there from HN. Alas, workaround and not an actual solution to your point.
The idea is that MemLink enables you to put content on the web with zero friction - no hosting, no deploying, no storing. You author the content, and it simply exists such as any other content asset that you could share.
Very much still rough around the edges. The editor supports dragging the blocks to reorder. Not all of the block types are hooked up yet. There is a custom shorthand syntax to each block metadata value to adjust settings like theming, positioning, and size. The plan is to polish up the authoring experience and abstract away the shorthand for UI controls.
Some issue seems to be:
1) distribution/lack of update mechanism. If you edit your site and someone has an old link, they don’t just get the update.
2) the links are ugly - works great with url shortening services though
3) there’s a size limit to the query param. Working on some dynamic data blocks that would allow you to pull content from other places such as a google sheet or bucket.
Any ideas or suggestions? Please let me know.
Thanks for checking it out!