How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
> Markdown files are slightly annoying to read/preview
Maybe I’ve missed the intentions of markdown, but the ability to easily read the plain text version has always been the killer feature.
Rendering as html is a nice bonus.
I understand there are plenty of useful things to say “but what about…” to, like inline images, and I use them. But they still detract from what differentiated markdown in the first place.
The more of that you add, the more it could have been any document format.
https://sdocs.dev/s/{short id}#k={encryption key}
└────┬───┘ └───────┬──────┘
│ │
sent to never leaves
server your browser
We encrypt your document client side. The encrypted document is sent to the server with an id to save it against. The encryption key stays client side in the URL fragment. (And - probably very obviously - the encryption key is required to make the sever stored text readable again).
You can test this by opening your browser's developer tools, switch to the Network tab, click Generate next to the "Short URL" heading, and inspecting the request body. You will see a base64-encoded blob of random bytes, not your document.
I can't believe I'm saying this, but this should be an Electron app. Or Tauri or whatever.
Seriously, it's a really nice Markdown app, but the "launch a CLI to urlencode your file" flow is such a messy way of doing this. Just open the file like any other app. Sure, the web version is convenient for demonstrating to people or one-off use, but it's no way to work day to day.
As for the motivation... "Fiddly to send/receive"?? Just send the file like you would any other. Don't you have to send other files? So you already have a way of doing this. Just do that. Bonus points for being able to easily receive an edited file, make diffs, etc., as well as the person on the other side being able to use whatever viewer/editor they prefer, not the one you pushed onto them.
How is sending a GIGANTIC link any better? If your file is nearly as long as the shit my LLMs write, you'll reach the chat character limit on most platforms, even though the file itself is well within file upload limits. And now there's a link shortener to solve this problem, which just defeats the purpose of it being offline and independent of a cloud service.
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 misunderstanding something and is there a stronger mechanism in browsers preserving the fragment data's isolation? Or is there some way to prove a url is running a github repo without modification?
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 the previous one.
Your styling-via-frontmatter is the same mechanism applied to presentation. Have you thought about a read mode that exposes the frontmatter as structured data, for agents that consume sdoc URLs downstream?
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.
Copying the content directly is actually more reliable. A curl-based fetch adds a network dependency and now your agent workflow breaks if the service is down. If you're already treating these as structured state (as fredericgalline describes), just keep the files local and pass them directly. The URL sharing is for humans, not agents.
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.
So the only durable share mechanism requires users to not lose the URL fragment. That's your recovery story: "don't lose the tab." Fun until someone closes the browser.
i also used fragment technique for sharing html snippets but url's became very long, i had to implement optional url shortener after users complained. Unfortunately that meant server interaction.
https://sdocs.dev/s/{short id}#k={encryption key}
└────┬───┘ └───────┬──────┘
│ │
sent to never leaves
server your browser
We encrypt your document client side. The encrypted document is sent to the server with an id to save it against. The encryption key stays client side in the URL fragment. (And - probably very obviously - the encryption key is required to make the sever stored text readable again).
You can test this by opening your browser's developer tools, switch to the Network tab, click Generate next to the "Short URL" heading, and inspecting the request body. You will see a base64-encoded blob of random bytes, not your document.
Re URL length: Yes... I have a feeling it could become an issue. I was wondering if a browser extension might give users the ability to have shorter urls without losing privacy... but haven't looked into it deeply/don't know if it would be possible (browser extensions are decent bridges between the local machine and the browser, so maybe some sort of decryption key could be used to allow for more compressed urls...)
We hit the same wall — URL compression helped but only bought us a few months before the complaints started again. Server-side storage was inevitable. The trick was making it feel lightweight: just a hash, no accounts, content expires after 90 days. Users barely noticed the "server interaction."
Using fragments for secure data has been discussed before on hn: https://news.ycombinator.com/item?id=23036515. Tldr: it may not go directly to the server (unless you are using a buggy browser or web client) but the fragment is captured in several places.
This is a neat tool. I always had to manually copypaste longs texts into notepad and convert it into md format. Obvisouly i couldn't parse complex sites with lots of images or those that had weird editing.
this will be useful
Thank you. If you use an AI agent you might be able to tell it to curl the target website, extract the content into a markdown file and then sdoc it. It might have some interesting ideas with images (using the hosted URLs or hosting them yourself somehow)
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.
We ran into the same pain with sharing markdown docs internally — the "just open it in VS Code" answer stops working when half your audience doesn't have VS Code. Ended up using a similar URL-encoded approach for a while. The real gotcha is file size; once docs hit ~50KB the URLs become unusable. Curious if there's a size limit baked in here.
Maybe I’ve missed the intentions of markdown, but the ability to easily read the plain text version has always been the killer feature.
Rendering as html is a nice bonus.
I understand there are plenty of useful things to say “but what about…” to, like inline images, and I use them. But they still detract from what differentiated markdown in the first place.
The more of that you add, the more it could have been any document format.