Live data from Hacker News

Show HN: SmallDocs – Markdown without the frustrations

news.ycombinator.com

21–30 of 53 posts

Re: Show HN: SmallDocs – Markdown without the frustrations

#21
A little update: I added privacy-focused optional shorter URLs to SDocs.

You can read more about the implementation here: https://sdocs.dev/#sec=short-links

Briefly:

  https://sdocs.dev/s/{short id}#k={encryption key}
                      └────┬───┘   └───────┬──────┘
                           │                │
                      sent to           never leaves
                       server           your browser

We encrypt your document client side. The encrypted document is sent to the server with an id to save it against. The encryption key stays client side in the URL fragment. (And - probably very obviously - the encryption key is required to make the sever stored text readable again).

You can test this by opening your browser's developer tools, switch to the Network tab, click Generate next to the "Short URL" heading, and inspecting the request body. You will see a base64-encoded blob of random bytes, not your document.

Re: Show HN: SmallDocs – Markdown without the frustrations

#22
post #10

i also used fragment technique for sharing html snippets but url's became very long, i had to implement optional url shortener after users complained. Unfortunately that meant server interaction. https://easyanalytica.com/tools/html-playground/

(I left a stand alone comment, but:) A little update: I added privacy-focused optional shorter URLs to SDocs.

You can read more about the implementation here: https://sdocs.dev/#sec=short-links

Briefly:

  https://sdocs.dev/s/{short id}#k={encryption key}
                      └────┬───┘   └───────┬──────┘
                           │                │
                      sent to           never leaves
                       server           your browser

We encrypt your document client side. The encrypted document is sent to the server with an id to save it against. The encryption key stays client side in the URL fragment. (And - probably very obviously - the encryption key is required to make the sever stored text readable again).

You can test this by opening your browser's developer tools, switch to the Network tab, click Generate next to the "Short URL" heading, and inspecting the request body. You will see a base64-encoded blob of random bytes, not your document.

Re: Show HN: SmallDocs – Markdown without the frustrations

#23
Nice implementation — the URL fragment trick for privacy is clever.

Related pattern I've leaned into heavily: treating .md files as structured state the agent reads back, not just output. YAML frontmatter parsed as fields (status, dependencies, ids), prose only in the body. Turns them from "throwaway outputs" into state the filesystem enforces across sessions — a new session can't silently drift what was decided in the previous one.

Your styling-via-frontmatter is the same mechanism applied to presentation. Have you thought about a read mode that exposes the frontmatter as structured data, for agents that consume sdoc URLs downstream?

Re: Show HN: SmallDocs – Markdown without the frustrations

#25

This is a neat tool. I always had to manually copypaste longs texts into notepad and convert it into md format. Obvisouly i couldn't parse complex sites with lots of images or those that had weird editing. this will be useful

Thank you. If you use an AI agent you might be able to tell it to curl the target website, extract the content into a markdown file and then sdoc it. It might have some interesting ideas with images (using the hosted URLs or hosting them yourself somehow)

Re: Show HN: SmallDocs – Markdown without the frustrations

#26
post #3
post #2

I had not heard of url fragments before. Is there a size cap?

Ish, but the cap is the length of url that the browser can handle. For desktop chrome it's 2MB, but for mobile Safari its 80KB. The compression algo SDocs uses reduces the size of your markdown file by ~10x, so 80KB is still ~800KB of markdown, so fairly beefy.

It's 2^16=65,536 bytes for Firefox

Re: Show HN: SmallDocs – Markdown without the frustrations

#27

Earlier quoted context omitted.

No, I don't have any good ideas. Just hoping someone else does, or that I'm missing something. I think it's in the hands of browser vendors. The agent review a la socket.dev probably doesn't address all the gaps. I think you're already doing about as much as you reasonably can.

Thanks. The question has made me wonder about the value of some sort of real time verification service.

If it's possible to isolate that part of the code, and essentially freeze it for long periods. At least people would know it wasn't being tweaked under them all the time.

That is my half of a bad idea.

Re: Show HN: SmallDocs – Markdown without the frustrations

#28

URL data sites are always very cool to me. The offline service worker part is great. The analytics[1] is incredible. Thank you for sharing (and explaining)! I love this implementation. I'm a little confused about the privacy mention. Maybe the fragment data isn't passed but that's not a particularly strong guarantee. The javascript still has access so privacy is just a promise as far as I can tell. Am I misunderstand…

For the "prove the server doesn't touch the data" problem — the realistic path today is probably reproducible builds + published bundle hashes.

  Concretely: the sdocs.dev JS bundle should be byte-for-byte reproducible                                                                                                         
  from a clean checkout at a given commit. You publish { gitSha, bundleSha256 }
  on the landing. Users (or agents) can compute the hash of what their browser                                                                                                     
  actually loaded (DevTools → Sources → Save As → sha256) and compare.                                                                                                             
   
  That closes the "we swapped the JS after deploy" gap. It doesn't close                                                                                                           
  "we swapped it between the verification moment and now" — SRI for SPA
  entrypoints is still not really a thing. That layer is on browser vendors.                                                                                                       
                                                                                                                                                                                   
  The "two agents review every merge" idea upthread is creative, but I worry                                                                                                       
  that once the check is automated people stop reading what's actually                                                                                                             
  verified. A dumb published hash is harder to fake without getting caught.                                                                                                        
                                                                                                                                                                                   
  (FWIW, working on a similar trust problem from the other end — a CLI + phone                                                                                                     
  app that relays AI agent I/O between a dev's machine and their phone                                                                                                             
  [codeagent-mobile.com]. "Your code never leaves your machine" is easy to                                                                                                         
  say, genuinely hard to prove.)

Re: Show HN: SmallDocs – Markdown without the frustrations

#29

URL data sites are always very cool to me. The offline service worker part is great. The analytics[1] is incredible. Thank you for sharing (and explaining)! I love this implementation. I'm a little confused about the privacy mention. Maybe the fragment data isn't passed but that's not a particularly strong guarantee. The javascript still has access so privacy is just a promise as far as I can tell. Am I misunderstand…

For the "prove the server doesn't touch the data" problem — the realistic path today is probably reproducible builds + published bundle hashes. Concretely: the sdocs.dev JS bundle should be byte-for-byte reproducible from a clean checkout at a given commit. You publish { gitSha, bundleSha256 } on the landing. Users (or agents) can compute the hash of what their browser actually loaded (DevTools → Sources → Save As →…

Ya. I could imagine a browser extension performing some form of verification loop for simpler webpages. Maybe too niche.

Re: Show HN: SmallDocs – Markdown without the frustrations

#30

URL data sites are always very cool to me. The offline service worker part is great. The analytics[1] is incredible. Thank you for sharing (and explaining)! I love this implementation. I'm a little confused about the privacy mention. Maybe the fragment data isn't passed but that's not a particularly strong guarantee. The javascript still has access so privacy is just a promise as far as I can tell. Am I misunderstand…

Thanks for the kind words re the analytics! You are right re privacy. It is possible to go from url hash -> parse -> server (that’s not what SDocs does to be clear). I’ve been thinking about how to prove our privacy mechanism. The idea I have in my head at the moment is to have 2+ established coding agents review the code after every merge to the codebase and to provide a signal (maybe visible in the footer) that, ac…

How about simply making the website an app and have it load your makedown file with a button and file browser. Just like e.g. https://app.diagrams.net/

And I believe you can then tell the browser that you need no network communication at that point. And a user can double check that.

Post reply on HN