[HN Gopher] Show HN: Memlink, a self-contained web page in a link
       ___________________________________________________________________
        
       Show HN: Memlink, a self-contained web page in a link
        
       Author : throwaway413
       Score  : 56 points
       Date   : 2022-05-28 14:30 UTC (8 hours ago)
        
 (HTM) web link (meml.ink)
 (TXT) w3m dump (meml.ink)
        
       | no-reply wrote:
       | I assume you would need some sort of hash/encryption to make sure
       | the link is not changed in anyway. I wonder who would need that
       | though.
       | 
       | Then again, with that long param at the end of the url, it looks
       | like it should be unique anyway unless the message is the same.
        
       | giantrobot wrote:
       | Similar to itty.bitty site[0].
       | 
       | [0] https://itty.bitty.site/
        
       | rurtrack wrote:
       | This is like my webpage drum loop app! https://drummy.io
       | 
       | I love this concept
        
       | kseistrup wrote:
       | This reminds me of blinkots: https://github.com/akumpf/blinkot
       | (I'm unsure if there are still any blinkot viewers around).
        
         | throwaway413 wrote:
         | 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.
        
           | kseistrup wrote:
           | Will it be open-source, I wonder? It would be cool to be able
           | to use other servers/viewers just by taking the right-hand
           | side after the /. It would also make it more resistant to
           | censorship.
        
             | throwaway413 wrote:
             | Indeed, I agree! I will definitely be open sourcing this in
             | the next week or two. Right now it's all spaghetti code
             | proof-of-concept (wrote most of it on my iPad touchscreen
             | on the couch...laziness?) but I've already started cleaning
             | and standardizing the pieces to be able to open source it
             | all.
             | 
             | 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.
        
       | valgaze wrote:
       | Reminds o hashify.me, ex:
       | https://hashify.me/WFhYIGFyZSBzZWxmLWNvbnRhaW5lZCwgbWljcm8gd...
        
       | SemanticStrengh wrote:
       | I managed to make it crash by spamming letters: > Unchecked
       | runtime.lastError: A listener indicated an asynchronous response
       | by returning true, but the message channel closed before a
       | response was received framework-a87821de553db91d.js:1 Error: code
       | length overflow. (23804>23648)
       | 
       | cool project btw
        
         | throwaway413 wrote:
         | 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.
        
       | mano78 wrote:
       | Brilliant! Quite clever and well-developed. I'll use it!
        
       | memalign wrote:
       | Thanks for sharing! I think it'd be nice for privacy if the data
       | came after a # in the URL so it's never sent to a server.
        
       | alex14fr wrote:
       | You could also use data: URLs to make it a true Serverless(c)(tm)
       | experience data:text/html,<b>hello world</b>
        
         | throwaway413 wrote:
         | 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.
        
           | andreisbc wrote:
           | If you need a tip on something like this it means you're just
           | discovering the web lol
        
           | kingcharles wrote:
           | Many things on the Net have a 2000 character limit for URLs.
           | Still, I bet some creative minds could do a lot in 2000
           | characters. We should start a demo scene.
        
           | shakna wrote:
           | I managed to fit a hacky text editor inside a URL [0] without
           | too many issues, and I didn't bother with any minification or
           | custom packing of the data. So you can easily take it a lot
           | further!
           | 
           | I found there were a lot of edge cases with data URIs that
           | made sharing them kinda annoying. Like email providers
           | stripping the data URI when you email it (not getting spam-
           | binned. The link would get deleted. Even if you left it as a
           | plain text email.)
           | 
           | Firefox doesn't appear to have a URL length limit.
           | Unfortunately, the world is standardising on Chrome, and that
           | absolutely does (about 2,097,152 characters for the entire
           | URI). Chrome also _sometimes_, but not always, opens a
           | data:text/html link in Quirks Mode.
           | 
           | [0] https://github.com/shakna-israel/selfedit
        
       | nyolfen wrote:
       | if anyone is curious, the link data is the following in base64:
       | 1;1|fig:MemLink;5;2;c|h2:In-memory micro web
       | pages;5;3;c|p:MemLinks are self-contained, micro websites that
       | are fully generated at the edge.|p:Use a MemLink to easily share
       | lists of links, contact details, project overviews, and so much
       | more.|h3:The link is the web page.;1;3|p:Memlink pages are
       | composed of blocks that can be added, removed, and rearranged to
       | make unique and creative content.|p:Create your own Memlink now
       | by clicking Edit this page below.
       | 
       | is this a bespoke markup format or just something i don't
       | recognize?
        
         | Cloudef wrote:
         | 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?
        
           | sgtnoodle wrote:
           | I'd imagine LZW would do a pretty good job without being too
           | complicated.
        
           | hombre_fatal wrote:
           | It's percent-encoded.
        
             | throwaway413 wrote:
             | Yep exactly - individual components of the string are
             | encoded at different stages to prevent pipes and other
             | characters from breaking the parser.
             | 
             | Clearly though all the kinks are not worked out as others
             | here have reported breaking it with some characters. Work
             | in progress for sure!
        
         | throwaway413 wrote:
         | 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.
        
       ___________________________________________________________________
       (page generated 2022-05-28 23:01 UTC)