Monod, our secure and offline-first Markdown editor, is open source | Hacker News Reader

Monod, our secure and offline-first Markdown editor, is open source

github.com

116 pointscouac67 comments

I never understood the purpose of markdown editors. Isn't the main selling point that markdown is a human readable plain text format (i.e., vim will do/you don't need preview)?

The other selling point is that you can use any/every editor you want, as long as it handles text. Sometimes it is helpful to use an editor with a live preview; other times it's preferable to use vim, or an ide.

I get that if you have a lot of tables, images, etc. live preview is useful but I always shake my head when I open up a Github-style README in a text editor -- they're basically unreadable. Why not create an editor that outputs markdown that looks at least somewhat like a human wrote it (wrap lines at 80 columns, put links at the bottom, etc.)

Agreed completely. An editor specialized to create human-readable Markdown would win my heart. Preview functionality is great, but a killer feature would be to make it easy to preserve the theoretical advantage of Markdown.

Theoretically. Unfortunately, Markdown has many potential ambiguities in interpretation, and unintuitive aspects.

Especially for GitHub, I don't want to iteratively push commit after commit to README.md just to get the correct syntax for their GitHub-Flavored-Markdown. When editing on GitHub directly, I appreciate the preview to spot mistakes.

However, there are many downsides of using the website for editing (like you can't combine changes to multiple files in a single commit). I prefer using a real editor locally, but using any other Markdown processor might give slightly different results. Therefore I use flavor [1] to filter the Markdown document through the GitHub API for reviewing it locally before pushing.

[1] http://brettterpstra.com/2012/09/16/easy-command-line-github...

I wrote mup [1] to help with this: it is a markup previewer. It support multiple markup formats and for markdown multiple markdown implementations: pandoc, commonmark, kramdown, python-markdown and also previewing using GitHub API (slow but the most reliable for README.md editing)

[1]: https://github.com/agateau/mup

Why not just use Pandoc with GFM syntax options?

flavor also includes CSS rules that closely resemble the design of GitHub, so I can view the result in my local browser as it would look on the GitHub website. With pandoc, I only get plain HTML output.

grip (on pypi) is also pretty good, and can serve rendered HTML on its own.

That is why initiatives like Commonmark (http://commonmark.org/) exists.

no.

It is a semantically readable text document, that is easy to write and understand by humans too. It really shines when you do something with it after you wrote it (e.g. make a html and style it).

I use it as a plain file/folder wiki and to have a future-proof format for the wiki.

Interesting idea. Found it useful and working so far? Care to share (part) of your structure?

I've always found wiki's and the like extremely difficult to organize. Lots of knowledge and little things, but it always runs out of hand quick.

It's an experiment and I'm trying to write all my notes in to it.

The problem is the associative/ribosomal nature of information and the quickly missing context.

We'd need to build a brain that gathers and understands context and files in all the cross-connections. Until google is done with that we are stuck with what's manageable: A hierarchy (folders) with some limited manual cross-links and full-text search.

I'm using the yellow cms, with a wiki plugin:

http://datenstrom.se/yellow/

http://developers.datenstrom.se/edit/plugins/wiki-plugin/

All running in a local http server. It's synced to my phone via Owncloud. On my phone I edit the plain files with JotterPad and sync with Foldersync.

But I'm not super happy with yellow:

- missing a tree view (I hacked together something but it's ugly) - special syntax for the title (but you can ignore it mostly) - special syntax for the wiki stuff - was difficult find the setting to change to .md file endings (bad/missing documentation) - requires an index.md in every folder

What is really nice: i can drop a file in to a public version of the wiki and send a pretty link to someone.

At first I was a bit puzzled why anyone would need to describe an editor as "secure"... but oh well, it is actually a web application. I can see the need now.

I cannot vouch for the security the editor mentioned here, but anything that handles external data has security concerns.

https://www.cvedetails.com/vulnerability-list/vendor_id-8218...

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3075

Did you read the article? It's an interesting way of making a rich shareable document that is readable by those you share the link with and not by anyone else, including those who operate the server, or those on the network route to you.

Well, that's the principle, I didn't look closely enough to see if their implementation can be trusted, but it's a fun idea.

Since the encryption key is in the URL I don't think it's fair for them to claim they can't decrypt.

It is in the hash/fragment of the URL, that part is client side only and is never sent to the server.

This obsession with react/electron/etc for the desktop is ridiculous. The OP acknowledges as much in the title ("secure" - what do you mean, it's a text editor, isn't it? Oh, because they decided to go "all web" for this!).

Use MacDown on OS X http://macdown.uranusjr.com and MarkdownPad on Windows http://markdownpad.com

I don't have any recommendations for Linux, unfortunately.

Then again, the whole point of Markdown is that it's basic plain-text syntax that can be prettified as HTML. Its entire raison d'être is that you _don't_ have to learn (or test) another markup language, but whatever.

In terms of cross-platform development I understand wanting to use browser technologies, but these off-line web-applications always feel so flaky and unintegrated. The Atom editor for example still can't switch languages for the spell-checker at runtime, even though browsers themselves can.

> I don't have any recommendations for Linux, unfortunately.

Vim works just fine for MarkDown, Gedit is not too bad either. The whole point of MarkDown is being readable both as text in an editor and formatted by a renderer.

MacDown and MarkdownPad Pro are the editors I use on Mac and Windows too. The Pro version of MarkdownPad has nice support for GitHub flavored Markdown, either using the GitHub API or with an offline renderer.

As much as I like MarkdownPad [Pro], it has its own bloat problem. It uses Awesomium [1] for the preview HTML rendering, which can really chew up a lot of memory.

The original version of MarkdownPad used the native Windows WebBrowser control, but the author didn't know the trick that allows that control to render in IE11 mode instead of IE7 mode. I reported it on their forum over a year ago [2] but it still uses Awesomium.

Anyone who needs to use an embedded web browser on Windows should grab the code in that forum thread. Getting the native WebBrowser into IE11 mode instead of the terrible default IE7 mode makes it a useful control. Since you don't need to bundle an entire web browser with your app, it cuts down the app size quite a bit.

[1] http://www.awesomium.com/

[2] http://forums.apricitysoftware.com/t/why-is-markdownpad-spaw...

It's pretty horrible, but it's the future unfortunately.

The web is ubiquitous. Everyone knows it, and so it's much easier to scratch whatever itch you have in a tech you know than a scary one (C!) that you don't; building for situations you understand (your fast piece of expensive apple tech connected to your fast internet) than ones you don't.

This is exactly what they said about Java in the late '90s and early 2000s, but I have never had any trouble avoiding (non-server) software written in Java, and I doubt I'll have any trouble avoiding non-web software written with web technologies, either.

Sometimes you have to do a lot of detective work to know what technology was used to make the software. Web-tech doesn't ask you to "install Java", for example when running the "web app" with Electron or nw.js

If it ever gets good enough that I can't immediately tell when using it, I'll probably have to change my opinion.

When developing in a higher level language like JavaScript you are less prone to buffer overflow code execution vulnerabilities, witch seems to be the most common security hole.

That's a non-point. There's nothing intrinsic about higher level language that prevents security holes. There are plenty of low-level languages that are immune to buffer overflows—Ada, Rust, D† (to an extent), Oberon†, Cyclone....

D and Ada have real and important software written in them, Rust has hype, Oberon is still actively developed, Cyclone influenced new languages (particularly Rust).

† Garbage collected by default

These days, it seems like XSS/CSRF are just as common.

There are plenty of options beyond C/C++ and JavaScript.

Sublime with MarkdownEditing is what I use. Does everything I need.

While I personally use emacs (spacemacs) now, but ReText is pretty decent editor for Linux.

It's available in ubuntu repos.

What does this have to do with Electron or desktop applications? It's a web site.

> I don't have any recommendations for Linux, unfortunately.

For Linux and any other platform. Emacs' markdown-mode (including its GitHub-flavored gfm-mode) works very well.

> "secure" - what do you mean, it's a text editor, isn't it?

One of its features is that you can easily share your document with someone else across the internet with transparent encryption built in, so that the owner of the server and those on the network route never see the document.

Most other text editors don't have that feature, without combining them with other programs and services. They certainly don't make it as easy to do.

It also isn't secure as a few of us have noted, since it suffers from a Cross-site Scripting (XSS) vulnerability: https://github.com/TailorDev/monod/issues/122

See my other comment about MacDown having 100% CPU issues, it's a relatively known issue with that app.

Bug report for devs:

    1) Edit a doc in tab A
    2) Open same doc in tab B
    3) Edit in tab B
    4) Edit in tab A
    Result: changes in tab A are not saved and there's no notice/indication/error message.

... now bugs aside, why would I want to use a text editor that isn't local?

Even assuming it works fine, what does this get me that $FAVORITE_EDITOR combined with the plethora of other sync methods (dropbox, google drive, onedrive, etc) get me?

It would probably be more productive to report this issue on their issue tracker. https://github.com/TailorDev/monod/issues

Sure but that means I also have to create a github account and sign in there too. I have no interest in that.

It also doesn't seem to track deletes too well.

oijljljh <del><del><del><del><del><del><del><del>

Leaves a character or 2 still rendered.

Fixed :)

I guess having a link to share and the "own your own data"

Both of which you get with $FAVORITE_EDITOR and the syncing sevice of your choice.

An offline editor for generating HTML (from Markdown) written in a framework running on top of a browser?

The irony was lost on someone somewhere.

You guys should sanitize for xss...

EDIT: removed example page since it wasn't clear to me that access to link means you can edit

I'll probably just stick with Sublime or VIM, and not be deploying my own markdown text editor to Heroku. But neat, I guess?

What Markdown standard does this editor use? Commonmark (http://commonmark.org/), Github Flavored Markdown, or something else? Is it possible to specify which standard to use?

it is CommonMark.

Nice work. I've added "monod" to the "Editors" list at js.libhunt.com. Cheers!

thank you!

For folks looking for a simple Github Flavored Markdown previewer I've been very happy with grip:

https://github.com/joeyespo/grip

The recent "Show HN": https://news.ycombinator.com/item?id=11518921

> offline first

> site doesn't work if javascript is disabled

Using codemirror - I would have thought prosemirror would have been a better fit. Wonder why.

I am currently developing my own Markdown editor and looked into CodeMirror, Draft.js and ProseMirror and I also plan to base it on CodeMirror. I think if all you need is "syntax highlighting" (maybe including font sizes for headlines) you are better off using CodeMirror. Of course, if you want some WYSIWYG functionality Draft.js, ProseMirror and the like may be more suitable (or even mandatory).

It would be cool if you could also edit the right side.

why oh why do we need another markdown editor?sigh I personally just use VS Code and it's been working fine.

Please don't post generic dismissals to HN. The fact that people like to make things is answer enough.

it dos use the files as the database right? I like it. The text is a little too big for my taste. I might actually use.

Yes, because we had to come up with something quickly (this project was part of an experiment to learn React.js), it is simple and it seems to work.

You can easily adjust the font size by zooming in your browser.

Please someone build an RST editor

how do I pronounce Monod?

Like Jacques Monod, https://en.wikipedia.org/wiki/Jacques_Monod. We don't pronounce the "d" I'd say.

If you are interested in a Markdown Editor App for OS X, Linux, and Windows (not browser based), which also support custom themes, and also supports emojis, and also supports GitHub Flavored Markdown and proper GitHub styles, then go star this repository of mine <https://github.com/niftylettuce/seuss.md>. While I appreciate that this was built with React.js, it still does not solve the problem of the need for a better Markdown editor. I'm almost positive Mou still doesn't have GFM support, and MacDown still has 100% CPU issues.

If you're going to self-promote, maybe have a README.md with useful info? Or have the repo link to a website that isn't down?

Reply on news.ycombinator.com