My basement flooded this week. So that's going to set me back a bit. But, hey, here's a quick update on the two FoC-relevant things I'm floating. • DANK WIKI • At the last FoC virtual meetup, we talked about setting up a super lo-fi, friendly-to-nontechnical-folks, hackable community wiki. I've got a repo all set up for that locally, and just have a tiny bit more experimentation to do before it's ready to share. All the pages are just simple HTML or MD. There is a build step — wait, stop, don't run away — it's a build step, but it's cool and different!! There's a really simple spec and a short reference implementation. Zero dependencies, less than 100 loc. Everyone is encouraged to port the script into their language of choice and commit that. That way, other people can check out the repo, add some pages, and build it locally without having to conform to whatever ecosystem the build script requires. I'd ideally like to have impls in each of the most common ecosystems right away (JS, Python, Ruby, maybe bash, etc). Finally, the wiki is (for now) going to be hosted on Github, with an action that runs the reference build script on commit, so if people want to edit it via the Github web interface they can. (I'll be liberal with handing out the commit bit). This is going to be a social experiment as much as a technical one. Excited to see how it goes. Hoping to have the initial version of this go live this weekend. • LIFE RAFT • I'm itching to get cracking on a Slack successor. I'm thinking I'll spin up a dedicated channel, and solicit people to drop in whatever random wishes / ideas / requests / suggestions / advice they feel like offering, so that these can filter in to the design process. I'm also hoping to put together goals for an MVP. This will need to include several things, including but not limited to: visual mockups for the GUI on desktop and mobile, technical architecture, priority features, estimated timeline. I intend to be quite restrained here — I want to make the smallest possible good enough thing.

It's been on my mind to come up with a schema for this. You've mentioned channel -> post -> comment before, and cerca has post -> comment. I feel we need something slightly richer that allows wiki-like workflows as well. Revisions. The ability to summarize a thread in a wiki page while maintaining provenance to the original thread (so another kind of revision?) The ability to create multiple views of a thing, qua Glamorous Toolkit. Maybe that's also another kind of revision? One challenge in combining markdown with an easy build script: markdown is notoriously hard to parse. Do you have thoughts on how to slice that tension? My thought so far has been to just restrict ourselves to a subset of html. Many forums and blog platforms allow html in comments but only a short list of permitted tags they can just mention below every textarea. That feels like one reasonable approach. (I'm so sorry to hear about your basement!)

I'm thinking we can get pretty far with a subset of markdown, parsed using a series of not-awful regexes. Here's what I currently have — cobbled together from a few different sources online, not well tested yet.

FWIW: I strongly favour the use of OhmJS (PEG) over the use of REGEXs... REGEXs fool you into thinking that they work, until you hit some edge-case that doesn't work. Unlike CFGs, PEGs can be used for simple parsing tasks instead of mega-project full-blown compilers. I would immediately jump to using OhmJS for parsing something like markdown.

https://djot.net/ is mostly markdown but is significantly easier to parse. You probably don't want all of djot, but studying what they changed to make markdown easier to parse seems worthwhile.

@guitarvydas I'm generally inclined to agree. Humblebrag: I work on a three-person team at my job, and Alex Warth is one of those three people. But in this case, I value the code being dependency-free and trivial to rewrite in other languages, so Ohm is probably out. So if we figured out a way to parse this subset of md syntax that satisfied the goals of this project, that'd be awesome. Would be happy to switch to that once it's figured out.

dependency-free and trivial to rewrite in other languages

Translation: only languages with built-in regex support are allowed, and let's hope that their notions of regex are sufficiently similar (probably not an issue unless you need advanced regexes, but... we will see). Just to point out the can of worms hidden behind any idea in the space of "let's keep data transformations simple".

This is strengthening my preference for "html (subset) all the way". Consistently across both wiki and life raft.

OhmJS (unlike Ohm?) is portable to every browser of note.

Reminder that the build script is a sideshow. The main attraction is authoring content for the wiki. That experience should be made as good as possible for as many folks as possible. This goal is in tension with the goal of making the build script stupid-simple and portable (in several senses — don't want to be tied to any particular host platform either).

Yeah, fair. I can live with a markdown subset. We just need to be able to clearly communicate what subset it is, that'll be part of the authoring experience.

@guitarvydas I meant OhmJS, sorry.

@Ivan Reese In your defence, a bird in the hand is worth two in the bush. And, my opinion is highly polluted by the notion that most existing 3GLs (Python, Haskell, WASM, etc.) are just assemblers and that OhmJS is the vehicle for making zillions of little DSLs using these assemblers.

We are re-enacting "worse is better" here: go for a simple solution that does 90% of the job and leaves the remaining 10% to the user to deal with? Or go for the Right Thing with a proper parser and proper error messages, at the cost of more code and some dependencies? The relevant question then is: will our users (present and future community members) be able to deal with the 10%, or will they give up when they can't get their contribution to render correctly?

@Konrad Hinsen But what different set of tradeoffs would you make? Can you find one that might better satisfy more people?

I think we have something similar to Zookoo's triangle: out of three desirable characteristics, we can pick any two. The three are: 1. Simple build system 2. User-friendly input syntax (Markdown) 3. Well-specficied build system (meaning an input format specification that actually corresponds to what the parser takes) If we give up 1, we use a Markdown-to-HTML compiler with a parser for something well-defined (Commonmark, djot, etc.). If we give up 2, we use HTML as our direct input format. If we give up 3, we use some regexp-munging for transforming something Markdown-like to something HTML-like. My personal order of preference is 2, 1, 3 (the number being the feature I am willing to give up). I am not going to give any arguments, because I can easily give arguments for any of the three choices. It really comes down to weighing them against each other. If everyone agrees that these are the trade-offs, we could do a poll to see what we mostly care about.

I appreciate the effort to find a framing that helps us think about this issue. But I disagree with the premise behind this particular framing. I think all 3 are achievable, and are already sufficiently achieved for the immediate needs of this project. The parsing worries expressed in this thread are missing the point of markdown. (For those who know their markdown history — I side solidly with Gruber, and solidly against Atwood.) I'm going to go ahead and ship what I've got. That's the spirit I'd like to engender with this project — just get something out there, it doesn't have to be perfect. If people try to use it and find that something about the setup impedes their desire or ability to contribute to the wiki, we can work on that concrete problem. I don't expect that what I have will work perfectly, especially not at first. That's a non-goal. The goal is to get people writing wiki entries. (And because I love a framing, even one I disagree with: 3, … … … … … … … 1, 2)

My point 3 indeed assumes Atwood's perspective on Markdown ("Markdown is a formal language"). I have a lot of sympathy for Gruber's view ("Markdown is a notation") but judging from the Markdown use cases I have experience with, it has failed in practice. It could perhaps be implemented robustly using AI, but there isn't much money to be made there so it won't happen. Side note: Markdown history deserves being studied in detail because it showcases many general issues with human-computer interfaces. That said, please go on with your project. "We believe in rough consensus and running code."