Good idea. Taking care of the hosting for inhouse pieces ourselves should also make it easier to track the project's written output. For some stuff it will be worthwhile having on Medium and decred.org because Medium pushes it to followers and makes it easy to engage by follow/clap.

Question-Should these articles be in a separate location than the blog or the same?

I like this a lot because it would enrich the website

@Dustorf not sure, we can discuss further, what would please me is if we had 2 separate parts of the site:

1. A blog section where individual/corp contractors could update their roadmaps and keep the community updated on what they're doing, much the way c0 has done.
2. A medium replacement that could hold all the amazing content our community produces.

@RichardRed0x I agree, the approach of duplicating content to maximize exposure until Medium pulls the plug makes the most sense.

@jzbz @Dustorf I have a backup of all Italian & Russian translations, just in case we need to move them.

I'm glad to see us thinking about it now. Now is a good time to reflect on the first incidents that affect crypto and plan ahead.

Good idea to treat medium as just one of the mirrors and use its advantages (increase exposure and engagement) without being hostages to its disadvantages (censored medium article won't affect other mirrors).

We shall keep warning all writers to back up their content.

@jzbz I have a certain design brewing in my head for a while now and it involves a different separation, primarily by acceptance criteria:

1. "fundamental" or "visionary" repository hosting pieces that shape Decred's future for years ahead. Curated by a small set of strategists. This is covered in Save epic Decred writings in Git #32.

2. A collective publication that includes anything like updates, roadmaps, research, opinion pieces, etc. Curated by our current lead writers.

A website can be built to publish content from both repos (a beauty of Git repos is you can merge them together), and it can be hosted under decred.org or on its own domain. We can figure it as we go, the most important is to design the data.

As for dcrweb and Hugo, I think it's better to not mix articles and other (heavy) site content. If the lightweight articles repository is kept separate, it will be easier for writers to work with and it can still be fused into the site nicely by the developers.

For great ideas like Decred, I care deeply about less discussed aspects of publishing texts which all serve the goals of knowledge perservation (censorship resistance, integrity and authenticity protection) and dissemination (simple replication and subsequent incremental sync, mirroring, offline reading). Another aspect is transparency and auditability of changes to disincentivize silent edits and hold authors accountable.

I see a path how to achieve all of the above with Git and Markdown. As seen in #32 and the earlier chat, I keep pushing for this approach because it is the only one I know that satisfies all the requirements. Despite Git being old, few projects bother to collect their knowledge in Git, but many projects still heavily rely on centralized 3rd party services to store their knowledge. Qubes OS is one good example of the former.

We can build the media that has resilience and transparency properties unseen (and unimagined) by most people today. Quite in the spirit of Decred, ha?

Authors willing to join in making this vision a reality will have to agree for the following sacrifices:

• Content cannot be removed after submission, it will be stored in Git forever. Best effort will be made to give proper attribution and due credit.
• Accept the possible inconvenience of writing in Markdown or converting existing articles to it, and submitting them to Git. (I will help where I can and this will get easier as our tools and workflows improve).

I have no issues with that approach, but I do think it's important to also publish blogs, articles and research on the website. The website is where we're driving people to learn about Decred, so it should be a center for information. The content will be seen by the most eyes there. As I said, redundancy and security are both valued.

If we are willing to sacrifice editing of articles, then why not run one or more IPFS node and publish on it? We can also use IPFS hash for linking via dcrtime.

Both Git and IPFS can be anchored with dcrtime.

Git is tried and tested and is widespread, meaning there is software for all major operating systems. There are GUIs for Windows. I can install open software to work with Git in a few seconds with one command. You can even have an open source GitHub client on your Android phone from F-Droid. I am pretty familiar with Git, several writers are catching up and I can help them. GitHub adds a nice hosting and collaboration platform to Git, you can even edit with just the browser, which leads to more people engaged with less technical skills. Also we can seamlessly engage developers for review and feedback on articles where necessary, and if #76 gains traction then PR can also be plugged in to advice on PR aspect of the articles.

I know almost nothing about IPFS. It looks interesting, and Git workflow has shortcomings. If all necessary pieces of the puzzle can be replicated in IPFS I would definitely consider it. However, I cannot invest into researching that right now.

People familiar with IPFS are welcome to comment. Even if IPFS is not chosen for this project, we still need something like it for #26 and other applications.

my only Medium piece I ever submitted (which was about my experience as a Decred contractor) got my account frozen, and I had to go through much hassle to get it published (from reddit)

People say Medium does not have 2FA support. If that is the case, that's another reason to not use it.