I build this because I liked the HedgeDoc style but missed the option to use the same markdown and just use it as website somewhere. A stand-alone parser/renderer didn't exist.
With this static-hedgedoc project you can render your own markdown site. You can see a demo here that parses the markdown features page from HedgeDoc using this static renderer https://static-hedgedoc.sc2.nl/ All you need to do this too is:
- Clone the git repo
- Copy static-hedgedoc-demo.html as index.html
- in your index.html replace static-hedgedoc-demo.md with your markdown file, you should put it in the same folder as index.html.
- If you like the style as-is then you're done at this point with making edits.
- Upload to your site and done
Do read the github project page as there are caveats, there are bugs and it is still work in progress! I used mostly all of the same js projects as HedgeDoc uses to be as comparable as it can be. I did use the latest versions of libraries (HedgeDoc uses really old ones) which will cause some subtle differences. Also, all the js files (all resources really) are served from your site, not a single link to a CDN. Still, loading a site "only" involves about ~700kb of datatransfer so not too bad.
Todo: I want to make a separate project that uses static-hedgedoc + some glue to create a split-view editor/preview (like HedgeDoc) but just as editor without any of the fancy collaborative features.
Which link do you pass to someone when sharing that? It's going to be one of those, if any goed offline your image will be perceived as offline even though it's there on other sites.
In a decentralized world with IPFS we can do the same thing through gateways. The gateway itself is a centralized endpoint through which you access content on the IPFS network. Here however the content of "cat.jpg" is hashed to a CID (Content ID). Let's say the content of "cat.jpg" has CID QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXfwfby9TpuuigE
On a first glance there isn't much of a benefit.
You need a gateway url (a central endpoint) and you need to know the filename (QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXfwfby9TpuuigE).
Now for the curl approach and why this is awesome.
Your image (QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXfwfby9TpuuigE) is accessible through any gateway. But when you pass this information to someone else, you don't want to tell them to use one specific gateway. You only want to tell them the content hash (QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXfwfby9TpuuigE) and let them use their own gateway. You want that because it promotes the data to be propagated over the IPFS network and be better accessible.
The curl patch _prefers_ that you use a own local IPFS gateway. So when you receive a link like "ipfs://QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXfwfby9TpuuigE" it would use the gateway it has locally. And yes, this is just url syntactic sugar as it's all eventually been rewritten to a full http-url. If you have a local node with this patch it will probably will rewrite it to "curl http://localhost:8080/ipfs/QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxX..." But you could also be using an IPFS node in your local network but not on your local machine, meaning it could also rewrite it to:
"curl http://10.0.3.3:8080/ipfs/QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXf..." (or whatever your network is)
But to you, as the user of curl, that all doesn't matter. You just do:
"curl ipfs://QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXfwfby9TpuuigE"
Granted, if you use a node that isn't a local node the curl won't find it and you'll have to manually specify it in your local "~/.ipfs/gateway" file or in the "IPFS_GATEWAY" environment variable. But these are one-time configuration steps.
Another thing i want to highlight is malicious gateways and verifiable data. This patch really should be considered as a low-level syntactic sugar to access IPFS, not as full IPFS implementation. One can build on top of this and do data verification. This is, at least that is my opinion now, not a place for inside of curl itself. (assumption here) You can do a streaming approach and verify it block by block with another application, which should be a valid usecase. Also it's very much in the philosophy of building 1 tool for 1 job. Curl is to get data from network resources, something else is to verify that that.
Moral of the story is that passing and IPFS url like ipfs://QmbjWyHqUyjxfq7KSiSLBi59CdpqwaAxXfwfby9TpuuigE becomes completely agnostic from central points. It becomes a local user setting to handle these urls. With IPFS still being young and still very much a niche technology, this is still somewhat of a hurdle to pass. But as IPFS gains more adoption like this, the hurdles become more and more streamlined to solve. At some point in the future people know that to use ipfs they install something that implements the ipfs protocol to use such links. Just like people know to use a webbrowser on http/https links, magnet links to be opened in a torrent client and mail links to be opened in a mail client (to name a few examples).
The spec itself is here: https://github.com/markg85/static-hedgedoc/blob/main/specs/p... but it's better to view it through my static renderer (https://static-hedgedoc.sc2.nl/?mdfile=specs/progress_bar.md) as it obviously supports my own extensions :) Github doesn't.
The code that implements this can be found here (markdown-it): https://github.com/markg85/static-hedgedoc/blob/main/js/mark...
Some short examples:
This would show a bar full at 25%, no text on the bar. Here no min and max is specified so 0 and 100 is implied behind the scenes [progress 25]
Same bar but with "25.00%" [progress 25 "{%:.2}%"]
Or just the percentage [progress 25 "{%}%"]
Or a more elaborate value (format is current | min | max) that also shows 25%: [progress 1000 0 4000 "{%}%"]