▦ 3 → Markdown
by: Shahruz Shaukat
Markdown & Frontmatter
Buzzard's already using Markdown w/ Frontmatter for each post. This offers a lot of flexibility.
-
Markdown's own standard is pretty comprehensive for generating static HTML.
-
Frontmatter means we can include any arbitrary key → value data into the post we want, which can be consumed by clients to figure out what to do.
-
Markdown has Remark, a plugin standard for extending functionality. There are some obvious plugins (code highlighting, oembed support, etc), but the plugin system allows for creating pretty much any "Markdown parser → HTML generator" flow.
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:
-
"Bots" are programmed to listen for new content somewhere, either through an always-online presence or by using a polling mechanism (checking to see if anything's changed on a regular interval, like every 60 seconds). These could integrate with platform APIs (Discord, Telegram, etc) or use more primitive scraping techniques (you could set up a bot to poll a website's contents).
-
"Webhooks" would be a more efficient approach where supported. In theory we could all have a Github repo full of our Markdown files, and anytime we push to our own repo, it'd call a webhook somewhere to see what's changed and update things accordingly in all the right places.
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?