Hacker News Reader

Comment by Hedja | Hacker News Reader

Always publish on your own platform then syndicate it across all the relevant social media providers to get exposure.

It's a huge pain, especially now that most platforms are closed and don't provide automation (APIs, RSS), but it's really the most flexible solution.

It also makes syndicating to new providers a lot less painful since you'll have some standard raw form (e.g. Markdown) which you can create a manual or automated pipeline for.

Considering Liberapay is using Mastodon, I expected them to already know what they're getting themselves into. Especially with Medium's thickening walls.

View on HN

Standard reminder that Markdown, while pleasant to author in, is perhaps one of the least standard formats ever (every implementation does things their own way; see Babelmark 2) and not a great archive format, largely as a result. (Markdown files don’t have version or flavor information embedded)

I hear org-mode is a good alternative. In the mean time, consider storing a permanent .html version upon publication of markdown

Commonmark is a wonderful and well defined markdown standard (ie the one GitHub uses)

Cited in the spirit of good humor, but not irrelevant: https://xkcd.com/927/

Serious question - how is it not irrelevant? Should it be posted any time people discuss the pros and cons of various standards?

To be fair, this is exactly what happened, since CommonMark did not cause all Markdown users and implementors to converge.

I’m not sure that GitHub uses CommonMark! Generally GitHub's format is referred to as GFM (GitHub-Flavored Markdown) and it has notable differences including preserving newlines.

Notably, GitHubbers and StackOverflow representatives joined to define CommonMark, but GitHub and StackOverflow do not have remotely similar fenced code block conventions.

Also, CommonMark currently says that they have not yet defined a version 1.0 of the spec.

I certainly applaud the effort, but CommonMark did not unify all the Markdowns.

Markdown is thirteen years old. This is older than HTML5, which introduced '<article>', '<section>', '<header>', '<footer>', '<figure>', and '<aside>'; and it's older than lots of modern CSS features. I've got archives in a variety of markup languages going back several decades; I've found old Markup easier to work with than old HTML or SGML. YMMV, though.

If your documents are available on the open web, you can visit them on the Wayback Machine to make sure they're cached as HTML. This is in some ways more reliable, and some ways less, than trying to keep track of your own HTML transcodes over decades. It's generally a more reliable way of making sure they're available after you disappear.

Standard reminder that Markdown, while having no formal standard, tends to be implemented in broadly compatible ways across various systems. Yes, there are edge cases -- yes, I've seen the lists comparing different renderers; yes, I've run into differences once in a while myself -- but in general, it turns out that the Markdown documents I wrote 15 years ago are still perfectly readable today, no matter what Markdown engine I drop them into. Or, you know, even if I don't drop them into a Markdown engine, because the entire point of Markdown is to be easily human-readable, without "looking like code," before rendering in the first place.

Markdown isn't the be-all and end-all of markup formats, and there are valid reasons for using formats with strict specifications (e.g., AsciiDoc or ReStructuredText for certain kinds of technical writing). But the chances of Markdown documents suddenly being woefully unreadable in 20 years are roughly in line with the chances of plain text Unicode documents being unreadable in 20 years.

org-mode is even less standard than markdown. The one and only editor for it is emacs. I haven't seen another implementation that is even close to complete.

As a daily user of org mode for notes, agenda, todo lists and word-processing (I LOVE IT) I'd recommend against using it for sth. like a blog. I did try. First of all it's a moving target, new syntax is introduced not-infrequently. Then, the API is cumbersome at times, and it's also slow. My org-publish setup with an RSS exporting function bolted on took many tens of seconds to export, even when only a single file was modified. I migrated to Textile for my website. It's implementations are all compatible, and it's way more comprehensive than any version of markdown.

Markdown is IMO good enough to archive.

The major point of using markdown, or why I use it, is that it doesn't require a working implementation to be understood. I can open a markdown file in ed and still understand it. From what I've seen of RestructuredText and Org-mode, if i'm not using the implementation, it becomes a mess.

(I also always recommend to put anything that isn't widely implemented in Markdown in HTML instead since that will be reasonably parsable for the next couple decades.)

The question is what is your platform? Does it require running your own server in your bedroom, hiring a virtual machine, or maybe even anything like hosted WordPress counts as yours, because you pay for it directly? And you know even if you run your own bedroom server - even then you still rely on some companies, be it your internet provider or even electricity provider, and theoretically you can be switched off if you offend them enough. This is a complex world.

The “threat model” approach from security is useful here too. (Or Business Continuity / Disaster Recovery, if you're familiar with that domain, or want to learn it.)

What are the threats to your content availability — hosting provider censors you, hosting provider dies, your cloud servers die, your on-premise servers die or their storage is corrupted, your workstation dies or its storage is corrupted, you miss a bill, you lose your ability to pay bills at all?

How likely are these? What happens? How much do you care? How could you recover and re-publish your data? How quickly do you need to recover, if at all? How much (time, money) is it worth investing now, to reduce the risk of future data loss or the duration of an outage?

Medium even has options to import copies of posts from your main site and an API for it, which they haven't gotten rid of yet.

They don’t have a reciprocal export function, however. :(

> Always publish on your own platform

What does "your own platform" mean? Without relying on things like Tor, I don't believe it's possible to publish anything without relying on some large corporation who can pull your content with a day's notice. If not Medium, it'll be AWS or Google Cloud or your domain registrar. Anyone who cares about an open web should be, at minimum, calling out those who take down content on short notice without reason.

The source at least should not be on the platforms: I shouldn't need a web connection to work on my content

Your own domains are orders of magnitude safer from that in general, so I think "our own domain + content in a form we can quickly mirror to another provider" qualifies as your own platform.

Domain registrars are orders of magnitude less likely to censor content than user-generated content sites. Hosting providers vary on this issue, but they're a commodity and some do take a hard non-censorship line.

I agree we should call out sites for censorship, but there's a strong case for people taking more control over their publishing.

> Hosting providers vary on this issue, but they're a commodity and some do take a hard non-censorship line.

Nearlyfreespeech and Gandi comes to mind here, I'm sure there are others who try to set as clear stance about their TOS. In general for web hosting though you should research that they have good connections, don't over-provision and have competent staff.

The point is there are tons of cloud hosting / self hosting / hosting over tor... Do you think piratebay would have survived a medium take down if they centralized through a service like that.

Reply on news.ycombinator.com