Hacker Newsnew | past | comments | ask | show | jobs | submit | FailMore's commentslogin

I’ve been building something somewhat adjacent to this. It’s https://sdocs.dev. It’s as 100% private browser based Markdown renderer

It's nice to see people building things, but honestly I found the demo video a bit disappointing. A bit too slow, a bit too choppy, a bit hand wavy. It didn't make me grasp why I needed this in my life.

I like it. I am building something very agent-use focused (https://sdocs.dev) and I’ve been thinking of introducing a /agent-evaluation page, which an agent can curl to then discuss with their user if SmallDocs is right for them. I really like the agent action to email flow. I’m introducing user accounts + subscriptions soon and think I’ll use that.

And now we see the beginning of how even local LLMs will be turned against their users -- by persuading agents to advertise to them.

I don't think that's what you're intending here, but it's the next logical step. Agents are on the Internet, and they represent an opportunity to reach their humans.


Thanks very much. I found that a very thoughtful reply

This is exactly my view and exactly what I’m building at https://sdocs.dev.

It’s Word if it were for cli based agents. It’s cli-first, markdown first, and you rarely if ever create the docs. Instead you tell your agent, “research X and give it to me in a sdoc”, or “sdoc this bug report so I can share it with Andy”.

It was discussed on a Show HN here: https://news.ycombinator.com/item?id=47777633


Nice, this feels very aligned with the direction I was trying to describe.

I’ll take a closer look at sdocs. Thanks for sharing!


1) Very nice implementation 2) Very nice domain! Did you always own "files.md"? 3) Re storing things on your server, what is the security layer around that?

I have been building a slightly different solution to the same problem. So far I’m pretty happy with the results and I have enough returning users that I think others are too (https://sdocs.dev/analytics).

I’ve built SmallDocs (https://sdocs.dev; Show HN: https://news.ycombinator.com/item?id=47777633).

SDocs is cli (`sdoc file.md`) -> instantly rendered Markdown file in the browser

When you install the cli it gives you the option to add a note in your base agent file (`~/.claude/CLAUDE.md`, etc.). This means every agent chat knows about SDocs and you can say “sdoc me the plan when you’re done with it” and the file will pop open instead of you having to find that terminal session to know it’s done.

Going browser first means you’re not required to install anything to get a great experience.

Despite being in the browser, the content of SDocs rendered Markdown files remain entirely 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've enjoyed exploiting the HTML rendering side of things which is possible by displaying Markdown in a browser. I’ve added tagged code blocks that the agent is given documentation on how to use. Eg ```chart or ```mermaid (for mermaid diagrams). These then become interactive elements on the page (mermaid is best example of this currently). See live renderings of these options here - charts gallery: https://sdocs.dev/s/yO3WbxFf#k=arcDBnizla5n437VFAeiQcwlu8kh_..., diagrams gallery: https://sdocs.dev/s/B_Ux11DV#k=KsvheEkiBFai6acnoIJnrOdfVRS5u...


> Very nice domain! Did you always own "files.md"?

Thanks! I bought it about 3 years ago. Back then, the project was just a chatbot.

But already back then, I kind of had an idea where I want it all to go.

I wanted the simplicity (and 0 cognitive load!) to start right from the domain name! Files in .md - files.md!

> Re storing things on your server, what is the security layer around that?

For the most part I use the project from my Telegram bot. And due to that, it is not possible to do proper E2E.

Will see if people use the chatbot, if not, we can consider E2E.


I've been experimenting with a fairly vibecoded Office 365..., but rooted in the world of vibe (an advanced Markdown reader which can do complex things like render charts and mermaid diagrams, see: https://sdocs.dev, https://sdocs.dev/#sec=charts, https://sdocs.dev/#sec=diagrams). Slides coming soon too... But this is very much a subsection of the full Office suite.

(Also discussed on HN here: https://news.ycombinator.com/item?id=47777633)


I’ve built SmallDocs (https://sdocs.dev; Show HN: https://news.ycombinator.com/item?id=47777633; live usage stats: https://sdocs.dev/analytics).

SDocs is cli (`sdoc file.md`) -> instantly rendered Markdown file in the browser

When you install the cli it gives you the option to add a note in your base agent file (`~/.claude/CLAUDE.md`, etc.). This means every agent chat knows about SDocs and you can say “sdoc me the plan when you’re done with it” and the file will pop open instead of you having to find that terminal session to know it’s done.

Going browser first means you’re not required to install anything to get a great experience.

Despite being in the browser, the content of SDocs rendered Markdown files remain entirely 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 liked the article and the term thinkism (which I hadn’t heard before). I think education should be radically changed to be about doism instead. I think it’s likely we have more engaged kids learning more valuable life skills.


I agree that doism should done more in all honesty

Cuz in real life also its more about "doing" you're physically fixing a clock, or writing code, or designing a building

Doism shouldn't be 100% but it certainly should be more


I think it was Hamming who said that some of the best researchers can only think well when they have a bench full of equipment in front of them.


Reminds me of https://xkcd.com/927/ - and to avoid confusions: everybody has good intentions and think they know better.

We definitely should try to improve and experiment with any system, including education, but I really doubt it is that easy to improve education and it will depend on objective, culture and political environment more than doing A or B.


SmallDocs person here, IMO the location of Markdown files and the reading of them are separate things. SmallDocs is just about reading not about storing. Eg if you are working in ~/code/my_project, and have a README.md, you (or your agent) can `sdoc README.md`. This opens up the file for reading (in the browser, but 100% privately). It doesn’t change the stored location of the Markdown file.

Is that what you were getting at or something else?


Ah its a reader, okay, great tool!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: