Replying to TheOneWithAReallyLongName

I was intrigued to see AsciiDoc in the NIP as I was unfamiliar with it at the time, but the more I've looked at it and played with it, the less I like it for this. It doesn't read as nicely as markdown in raw form, it comes with a lot of features that don't make sense for individual articles themselves, and like you point out, the NIP isn't even compliant since wiki links override some of the anchor syntax.

If it's gonna be markdown, though, there does need to be more effort to specify flavor. There are tons of options, but none of the NIPs I've seen for markdown styled content specify a flavor. I'm fond of Pandoc's markdown since it has a rich feature set and pairs with a high quality conversion tool, but the important thing is making sure everyone is on the same page.
Avatar
Lez 5mo ago

I like the approaches in Pandoc markdown, and you are right, it would be great to have a settled format. Pandoc is nice and logical, but in the end I think it makes sense to choose a format which is already widely accepted by developers in the git{hub|lab} world.

Another thing that will count is the availability of an editor. I have recently bumped into this one: https://github.com/cesardeazevedo/nostr-editor

If it would be easy to drop it in a web app without hassle, that would lower the barrier of entry for markdown in apps, and probably drive motivation to standardize.

I will play around with the editor soon.

Reply to this note

Please Login to reply.

Discussion

4a
TheOneWithAReallyLongName 4mo ago

Developer familiarity shouldn't be the top priority in my opinion. It should be establishing a standard that maintains familiarity and ease of learning/using while ensuring a sufficiently rich feature set. Pandoc markdown shares its base features with most other markdown flavors while providing a lot of extra features for things like tables, math symbol integration, etc., that will be important.

Keep in mind that the real end user of the wiki format will be subject matter experts. Any sufficiently broad wiki will need input from lots of experts, and they will need the tools required to properly express information on their topic of specialty. Anything they need that isn't in the base spec is going to get custom rolled to fit their needs, and we'll start to see incompatibilities arise as different clients handle those needs in divergent ways. They're also in no way guaranteed to be software developers, so they're unlikely to have much familiarity with developer standards and tools.

Avatar
Lez 4mo ago

I agree that non-tech end-users will be the main target audience. But they are the ones who will dominantly use the visual editors with its buttons / hotkeys instead of editing markdown directly. Few of them will use the visual editor's input rules feature either (when you enter *xx* and the editor turns it to italic in place.

The ppl who use the markdown syntax directly are mostly developers, that's why I believe their opinion will have more weight.

4a
TheOneWithAReallyLongName 4mo ago

Hmmm you might have a good point about who's actually going to directly interact with the chosen syntax. I'd be interested to see stats on that from somewhere like Wikipedia. I'm sure you're right, I just wonder to what extent.

Still, though, a wiki requires a more complex syntax with a richer feature set. Regardless of how the users interact with it, it's absolutely critical that the chosen flavor has all the features we need from the start. Once different sites and clients start doing things their own way, it can get really messy, and interoperation can take a big hit.

Avatar
Lez 4mo ago

No idea about the statistics unfortunately. Just the fact most publishing platforms has visual editors nowadays.

Features that come to my mind right now (on top of basic features):

tables, sub-text, footnotes, math equations, images with upload and caption text, alerts ("this page needs this or that"), numbered and bullet point lists, code blocks with syntax highlighting, (block) quotes, table of contents, front matter (for homepage, author info, etc), and all the nostr stuff described in NIP-54, including wikilinks. The terminology was grabbed from here: https://docs.gitlab.com/user/markdown/

At least that's for start. I also believe that a nostr flavour markdown spec would be helpful for wide adoption and tool interoperability.

I created an article for it in tribewiki for quick listing the features: https://tribewiki.org/Markdown-fmt