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.

I feel your pain. My project is https://sdocs.dev, the homepage is actually the rendering of a markdown file (sdoc.md), so you can see how SDocs renders immediately. There are some links on the homepage to other Markdown files with some elaborate styles and charts

Maybe not a direct answer to your question, but https://sdocs.dev has a cli built for agents. ‘sdoc —help’ and ‘sdoc schema’ and ‘sdoc charts’ teach your agent how to use it. You can try it with ‘npm i -g sdocs-dev’

Putting the markdown in the URL, that is very clever!

This is cool. Can you tell me more about the :: blocks thing. I didn’t know that was a Markdown element.

This problem has risen to the top of many people’s minds at this moment (including mine!). My Show HN for a similar cli + web based solution (https://sdocs.dev) is on the /show page now (https://news.ycombinator.com/item?id=47777633).

I also went with Front Matter for styling and added an interactive styling mode you can do on the web to test it out immediately. There are some examples on my homepage which demonstrate it in action.

SDocs is cli -> instantly rendered on web

Despite being in the browser, the content of SDocs rendered Markdown files remain local to you. SDoc urls contain your markdown document's content in compressed base64 in the url fragment (the bit after the `#`): https://sdocs.dev/#md=GzcFAMT...(this is the contents of your document)... The url fragment is never sent to the server (see https://developer.mozilla.org/en-US/docs/Web/URI/Reference/F...: "The fragment is not sent to the server when the URI is requested; it is processed by the client").

The sdocs.dev webapp is purely a client side decoding and rendering engine for the content stored in the url fragment.

This also means you can share your .md files privately by sharing the url.

Also, I’m sorry I high jacked your post to some degree with this comment. It’s just a little too relevant for me not to leave a comment!

> Can you tell me more about the :: blocks thing. I didn’t know that was a Markdown element.

They are Markdown directives

Tyvm