Home Blog Games
Jun 06, 2021

▦ 3 → Markdown

by: Shahruz Shaukat

Markdown & Frontmatter

Buzzard's already using Markdown w/ Frontmatter for each post. This offers a lot of flexibility.

Blocks

The post about Subtext - the Markdown-like format that includes a syntax for referencing other posts - has a useful concept of "blocks". Instead of treating a post written in Markdown as one thing, it breaks each line / section into it's own "block".

These blocks would create the possibility for something more like Notion, each element being something that could be forked into it's own post or response. Being able to comment on something within a post as opposed to the entire post seems useful too.

Ingesting w/ Bots & Webhooks

It seems like it'd be relatively straightforward to ingest information from any outside source (Discord, Telegram, Twitter, etc) and convert it into Markdown.

The most basic format would be taking the body text from the source and plopping it into a Markdown file as-is, with a bit of manual processing to ensure links are clickable, then publishing or storing that Markdown file in the right place (which could be Github based on the current setup, but could also happen on IPFS and a blockchain).

There's two technical forms that would cover most outside platforms I think:

Interactivity

A huge limitation with all this is interactivity. Markdown's really just built for generating static content, not for any kind of back-and-forth communication between the publisher and their audience, or their audience amongst themselves.

I wonder if there's a way to define new primitives that are easy to compose in Markdown, and there's an expectation that a Buzzard "client" knows what to do with it.

For example, if in Markdown we could just write something like:

<Comments />

And set up a Remark plugin that sees that tag and knows to replace it with some predefined HTML / CSS / JS, in this case creating a comments box on the page in that location. Because JS will be executed client-side, the Comments widget could figure out what URL it's on and know which threads to pull in.

Because it's HTML (or JSX) tags, parameters could be added to any of them for customization:

<Donate recipient="@EFF">

This would embed a generic donation widget that directs all funds to a certain address or user.

<Fundraiser
  recipient="0xBb167bCe93F2e1Db5aAe834702C8BDAEaB5e9831"
  goal="100"
  title="Fund development for XYZ"
/>

With Web3, where backend APIs are decentralized, scalable protocols, you could write a matching contract for each type of functionality and hardcode that contract's address into the HTML / JS template. That way the generated frontend code can run anywhere at any time, without any concern of Buzzard hosting and maintaining it's own APIs, and dealing with the inherent problems of scaling a centralized service.


🕊 Where to next?

▦ 4   →   Infinite Space Notes

▦ 6   →   Interplanetary Filesystems

▦ 8   →   Faucets