A couple of years ago, I wouldn't have believed we would be seeing essentially zeroconf TLS/PKI in software anytime soon. Letsencrypt, the "encrypt everything" movement, and people like Steve, Ponzu's author, have improved internet security tremendously at a time when it is critically needed.

Quick question, must the server use "Let's Encrypt" be public on internet to use it?

Like: Can I use private ip (10.1.1.x) behind the NAT and still use "Let's Encrypt" + your CMS/server?

Thanks

There are other tests that the ACME protocol can do to determine authority over a domain name, but Ponzu's implementation doesn't handle them.

Sorry if that doesn't fully answer your question.

If you get a chance to try it out and have questions or issues, I'm in the #ponzu channel in the Gopher's slack org: https://invite.slack.golangbridge.org/ feel free to ping me there or open an issue on Github.

Steve

Overall A+ to Ponzu. I'm on my 6th ponzu site now, still love it.

Lastly, here's to the hope of an exploit named "Pwnzu" never getting released! It's simply too good of a name.

I can't tell if that's an MVP type decision and will change later, or a design decision that won't change in the future.

The reference is stored as a string (or []string if you opt for a reference.SelectRepeater input func), but the value stored as a reference is actually a URL path to the content as it would be accessed via the Content API. This becomes very powerful when you enable HTTP/2 Server Push, and declare the referenced content to be pushed when it's parent content is requested.

The underlying data looks like this:

Song

id: 1

title: "Take Me Home, Country Roads"

artist: "/api/content?type=Artist&id=2"

If you enable H2 Server Push by implementing the Pushable interface (add a Push method that returns a []string of the JSON field names to push), the server will know to make a response for the referenced Artist field and push it down to the client when the parent Song is requested.

It's so annoying to me that so many CMS's and static site generators start out with the assumption of 1 big rich text / markdown "body" for content and treat everything else on the page as miscellaneous stuff (meta-fields, yaml front-matter, etc).

Is it for meta information about a post? Are those fields injected into a post somehow? How are those fields used? (I'm ignorant of CMSs)

The user facing html templates have variables that map back to those fields. So, all the expression of HTML, but with the actual data in fields.

Handy for things like addresses. You can render a map or just text, or both. The fact that it's structured data would allow for proximity searching. Where each "post" is say, a restaurant location.

Similar for things like tags, so that you have built in taxonomy. Separate spaces for tags too, so that you could have a topic taxonomy as well as a completely separate taxonomy that doesn't pollute that space. Like an author taxonomy or similar.

Others allow content relationships, where videos are their own object, set not to be published alone, but embeddable into, say posts.

Obviously rarely the case, but worth having the conversation.

in terms of this project, excellent, i actually wrote a lot of web apps using golang and found the main deficiency to be the templates, tried amber, ace, and even the default mustache/handlebars, but still think jade and haml beat those hands down. i did see a few ports of jade, but wqsnt certain about the stability or completeness of it.

I promptly shared my project based on a Japanese name and provided entertainment for a few mins.

As it keeps gaining traction and popularity, more and better tooling will inevitably be created to scratch itches :)

Thats my question...

I would love to get some feedback as a first time Bleve user.