This is very cool. It was obvious to me how to actually mix the paints, and I'd like a white for that.

Yep , exactly

Nice, I enjoyed it. Fyi I think you should edit the title to be "Show HN: <title>". This will mean it will be on the /show (https://news.ycombinator.com/show) page.

Thankss! Yeah, good tip.

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

that'd be great, thanks!

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.

https://sdocs.dev/trust Now lets you verify you're being served the actual open source code

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

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 beautiful.

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 <url> --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.

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

That's basically exactly what I'm working on now actually. We will let you compare all the publicly served files with their hashes on github

I feel like things have changed as the main interface for code has (for some) become an agent running in the cli. I feel like we (certainly I) check my code editor way less frequently than before. Because of that (for me) easily reading/rendering Markdown files has become more of a pain than it used to be.

If you problem is that you don't have a text editor open...just open it to read the file? When I click on a Markdown file, it opens in my code editor with the preview pane already open. Then I close it when I'm done. How is that different from any other file on a computer?

If your problem is that you don't want to use a text editor, there are many markdown viewers out there, both dedicated (MarkLite), as part of a larger tool (Obsidian) or even in an office suite (LibreOffice Writer).

If your problem is that you don't want fo leave the terminal, there are many command line markdown "renderers", at least as far as that is even technically possible (glow is markdown-specific, bat is more of a general fancy text file viewer).

I fail to see how any of these problems are even partially solved by a web app and a CLI tool that launches it, let alone any better than the existing solutions.