I really like the docs idea. I think it’s great to automatically render the side menu.

The prevalence of Markdown from agents made me work on something similar too. My Show HN for a similar cli + web based solution (https://sdocs.dev) was on the /show page a few days ago (https://news.ycombinator.com/item?id=47777633).

Sdocs is cli -> instantly rendered on web

I like the fact it doesn’t require you to install anything to get a great experience.

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.

I’m working on a few new features at the moment:

1. Commenting (so you can easily comment on a markdown file and feed that back to your agent)

2. A powerful slides functionality

This is a beautiful project. Well done.

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) was on the /show page a few days ago (https://news.ycombinator.com/item?id=47777633).

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.

This is a beautiful project. Well done.

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) was on the /show page a few days ago (https://news.ycombinator.com/item?id=47777633).

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.

I built https://sdocs.dev which solves this pain point.

You can “sdoc file.md” to instantly open it.

It was discussed on Hacker News here: https://news.ycombinator.com/item?id=47777633

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