Namecoin Forum

Hey everyone,

As was discussed at a recent #namecoin-dev meeting, I've ported the home page of namecoin.org to Jekyll. This eliminates the dependency on PHP (it's a static website), and makes it much easier to edit (people can submit edits as PR's using the GitHub web-based Markdown editor).

I also did some minor wording changes (which can be debated orthogonally to the switch to Jekyll).

Code is at https://github.com/JeremyRand/namecoin.org-jekyll ; you can see a live preview at https://jeremyrand.github.io/namecoin.org-jekyll/ .

Feedback at the #namecoin-dev meeting was positive, with Cassini, Hugo, Joseph, and myself in favor of switching to Jekyll, while John Kenney was in favor of switching to Drupal.

Thoughts on this? If we get consensus that this is a good idea, I'll port the other pages to Jekyll as well (won't be much work).

IMHO the web is not very important at the moment;
a way to access Namecoin core from a GUI and 2FA,
would be on top of my priority list, right after "follow bitcoin updates",
and "how to scale core and lite clients to process a lot of TX/nameops".

johnc wrote:IMHO the web is not very important at the moment;
a way to access Namecoin core from a GUI and 2FA,
would be on top of my priority list, right after "follow bitcoin updates",
and "how to scale core and lite clients to process a lot of TX/nameops".

Who said this thread was all I've been working on? If you don't care about the website, that's fine, feel free to ignore this thread. We have received significant criticism of the current website; thus it is useful to address that criticism.

Looks very good!
Your rearrangement/rephrasing of the text is also an improvement, I think.
I'd change the order of the items list inside the left column, though (move TLS validation further down). Maybe I should try a PR ...

Looks great!

ACK

I think the Jekyll port is very important because it fits with the Github workflow and it makes it easier to contribute new content.

cassini wrote:Looks very good!
Your rearrangement/rephrasing of the text is also an improvement, I think.
I'd change the order of the items list inside the left column, though (move TLS validation further down). Maybe I should try a PR ...

Feel free to send a PR.

Can we get feedback from Phelix or Daniel?

With php it is quite inconvenient for people to get a preview, which is bad. I guess this is easier with Jekyll?

Jekyll seems to be open source and does not make us depend on a remote server?

IMHO we should separate the infrastructure move from changes to the content.

phelix wrote:With php it is quite inconvenient for people to get a preview, which is bad. I guess this is easier with Jekyll?

With Jekyll, there are 3 ways to preview:

1. The content is in Markdown, so you can preview the content (without the site template) with any Markdown viewer (including the GitHub web interface as you're editing).
2. Install Jekyll on your machine, and run a single command to build the static HTML, which also launches a web server on localhost that you can view (with the site template).
3. Push your content to your own GitHub repo in the "gh-pages" branch, and GitHub will automatically launch a website that lets you preview it (that's how my preview link is generated).

(1) is easiest for while you're editing, (3) is still very easy and lets you see how the site template will look + share with others, (2) is unnecessary IMO but it's an option for people who like it. All three of these are easier than PHP.

phelix wrote:Jekyll seems to be open source and does not make us depend on a remote server?

That's correct; Jekyll is open source. We would install Jekyll on our server and set up a cronjob to pull from GitHub and run the Jekyll compiler. This is quite easy.

phelix wrote:IMHO we should separate the infrastructure move from changes to the content.

I'm totally fine with that.

In terms of security, a set of static pages has some advantages, basically by "refreshing" it periodically you make it immune from browser-based graffiti whilst the git-hub has some mechanism for tracking down deliberate defacing changes. Just a minor note, Atlassan has a "free-tools" initiative for some non-profit organisations so medium-term there might be advantages in using bitbucket over github.