Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: SmallDocs – Markdown without the frustrations

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 53 posts

Re: Show HN: SmallDocs – Markdown without the frustrations

#41

Post by FailMore »

edgardurand wrote: post #28
big_toast wrote: post #15

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 →…

My solution is now live at https://sdocs.dev/trust. Open to feedback

Re: Show HN: SmallDocs – Markdown without the frustrations

#43

Post by hatappo »

I am excited about this really cool idea. I read the update, but does it mean there are two approaches: one where you pack all the content into fragments, and another where you encrypt it on the client side, save it to the server, and reduce the content to data containing only the key?

Also, wouldn't it be better if the encryption and fragmented compression could also be handled on the web client side?

Re: Show HN: SmallDocs – Markdown without the frustrations

#44

Post by FailMore »

hatappo wrote: post #43

I am excited about this really cool idea. I read the update, but does it mean there are two approaches: one where you pack all the content into fragments, and another where you encrypt it on the client side, save it to the server, and reduce the content to data containing only the key? Also, wouldn't it be better if the encryption and fragmented compression could also be handled on the web client side?

That’s exactly what happens. We encrypt client side. The sever only gets encrypted data. You can inspect the network request to see what the sever receives. Your decryption key always stays client side (in the url fragment).

Also, the short URL (which saves the content in cypher format on the server) is optional. It only triggers if you specifically trigger it (by clicking “Generate” at the top of the rendered document). If you don’t click that everything stays client side in the fragment.

Re: Show HN: SmallDocs – Markdown without the frustrations

#45

Post by fredericgalline »

FailMore wrote: post #38
fredericgalline wrote: post #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 t…

I think the next thing I want to do (but not sure how to implement yet) is to make it easy for your agent to go from SDocs url to content. I don't know if that's via curl or a `sdoc` command, or some other way... That could include the styling Front Matter / the agent could specify it. At the moment the most efficient way to get sdocs content into an agent is to copy the actual content. But I think that's not too bea…

That direction makes a lot of sense. If sdoc could output raw content — or parsed frontmatter and body separately — to stdout, agents could consume it directly without a browser step. Something like sdoc get --format json piped into whatever the agent needs next.

The frontmatter-as-structured-data angle is where it gets interesting: an agent reading frontmatter as JSON could use it for routing, status checks, dependency resolution — not just presentation. Basically turning a sdoc URL into a queryable state artifact, not just a readable document.

Re: Show HN: SmallDocs – Markdown without the frustrations

#46

Post by saadn92 »

This is PrivateBin for markdown, right? Same URL fragment trick.

My actual problem with markdown isn't previewing, it's search. I've got maybe 50 .md files scattered across different project directories from AI coding sessions. Three weeks from now when I'm trying to remember where I wrote down how to fix some specific issue, grep -r is all I've got and it's terrible for this.

Re: Show HN: SmallDocs – Markdown without the frustrations

#47

Post by FailMore »

saadn92 wrote: post #46

This is PrivateBin for markdown, right? Same URL fragment trick. My actual problem with markdown isn't previewing, it's search. I've got maybe 50 .md files scattered across different project directories from AI coding sessions. Three weeks from now when I'm trying to remember where I wrote down how to fix some specific issue, grep -r is all I've got and it's terrible for this.

Thanks very much, maybe I can add something to ‘sdoc’ to make that easier

Re: Show HN: SmallDocs – Markdown without the frustrations

#48

Post by Nevermark »

FailMore wrote: post #36
Nevermark wrote: post #27

Earlier quoted context omitted.

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.

I have something coming out soon (just working on it). Your client (browser) has hashing algos built into it. So the browser can run a hash of all the front end assets it serves. Every commit merged into main will cause a hash of all the public files to be generated. We will allow you to compare the hashes of the front end files in your browser with the hashes from the public GH project. Interested to know what you t…

That sounds like a good idea. Any step toward transparent security is a good one.

Re: Show HN: SmallDocs – Markdown without the frustrations

#49

Post by dolmen »

My current frustration with Markdown is that Gemini is very bad at producing them.

Just because gemini.google.com uses Markdown for its output, it doesn't seem to be able to properly output Markdown from Markdown: always corrupted.

Just yesterday I asked gemini.google.com to write a README.md for a software project: the Markdown was broken from the closing first code block "```bash" and the rest of the doc was in the output like if it wasn't the doc anymore. An escaping issue. So I asked it to give me the same README.md encoded as Base64: once decoded the content was broken from the same point, but after that that wasn't Markdown anymore but binary data. It looks like Gemini leaked raw binary tokens in the Base64.

Very reliable tech. Is is too much to expect reliable Markdown escaping? Shouldn't this be a solved problem long ago?

Re: Show HN: SmallDocs – Markdown without the frustrations

#50

Post by FailMore »

fredericgalline wrote: post #45
FailMore wrote: post #38

Earlier quoted context omitted.

I think the next thing I want to do (but not sure how to implement yet) is to make it easy for your agent to go from SDocs url to content. I don't know if that's via curl or a `sdoc` command, or some other way... That could include the styling Front Matter / the agent could specify it. At the moment the most efficient way to get sdocs content into an agent is to copy the actual content. But I think that's not too bea…

That direction makes a lot of sense. If sdoc could output raw content — or parsed frontmatter and body separately — to stdout, agents could consume it directly without a browser step. Something like sdoc get --format json piped into whatever the agent needs next. The frontmatter-as-structured-data angle is where it gets interesting: an agent reading frontmatter as JSON could use it for routing, status checks, depende…

Interesting idea, do you have any ideas of states that could be particularly useful to have? It's not something I have thought of before
Post reply on HN