My March 2017 Personal Publishing Thoughts

created Mar 21, 2017

Define owning content

This is about content creators owning their content, whatever that means.

If I pay a monthly fee to Digital Ocean to use a server that houses my web publishing software and the content that I create, do I own my content when it resides on someone else's system?

I backup my posts by downloading the text markup files and the MySQL database dump files to my desktop Linux server. At the point, I know that I own my content.

I upload my photos mainly to Flickr, which I use as an image storage system. I don't care about Flickr's community features. I store my images at Flickr, and then I embed them into my web posts, created by one of my web publishing apps.

I download my photos to a hard drive and burn them to DvDs. At the point, I know that I own my photos. Same for videos.

When I setup a Tor .onion site on my Linux desktop computer that resides in my home, that's truly owning my content.

Customer or the product?

"If you aren't paying for something, then you aren't the customer. You're the product being sold."

I guess owning content could mean that the content and the author's actions are not re-purposed by the hosting service and used for advertising purposes.

Boghop is hosted, using Amazon Web Services. I don't think that Amazon is parsing this site and using my content as a product. Neither is Digital Ocean.

Open web vs silos

I would like to see more people post text onto their own corner of the web. If the service accepts video and photo uploads, that's even better. But the debate is about silos vs the open web.

I assume Instagram and Flickr are silos. But what about I could blog by using Instagram. How is that any different than creating a blog site with the Wordpress hosted system at

The site focuses on the Wordpress content management system that users can download and install on their server accounts.

But is different from from a silo vs open web perspective?

I don't know. It requires too much thought energy to define silos vs the open web with all of the exceptions. As long as it's easy for the author to download the content and copy it to a thumb drive, hard disk, or to DvD for storage purposes, then the service is fine.

I'm unsure if Instagram meets those requirements. I think that Facebook permits users to download their content.

Think long and slow

If the system is easy for the author to publish, and if the system encourages the author to create content at a regular interval, then that process is the correct method, regardless of what anyone else thinks.

The author can upgrade or modify the publishing process if the author gets bored and wants a change, or if the author learns more about the web and becomes an advanced user.

It's not helpful to push a beginner to become an advanced user immediately. A long, slow, organic process is preferred.

The independent web means site owners, after careful deliberation, can decide for themselves how their sites should function.

Most site owners want a drop-dead simple way of creating and updating content without having to learn a bunch of gobbly-gook, hip, technical concepts.

If the publishing system is easy, then people might use it.


For starting out, I would say creating an account at Blogger (or Google) and posting at works. Then maybe later, if still interested, migrate to another platform or method of publishing and use a personal domain name.

But keep it simple to start. The key is to publish every week. Not every day. That might be too much. But for starting out, publish any length at least once a week.

And just like with exercise, the goal should be still doing it five years from now at a regular interval with no major down periods.

Follow no political ideologies, regarding personal publishing on the web, including this page. Seek out and absorb the many viewpoints, and then define your own web presence.


Domain names

Buy a domain name and use it for your website, or don't buy a domain name, since that's one fewer thing that needs to be renewed at regular intervals.

Publish at Blogger,,, Ghost, Svbtle, Tumblr, etc., and if owning a domain name, point the name at your hosted site, if the service offers domain name mapping.

Your domain name can point to a Wordpress account where the content is hosted on Wordpress's infrastructure, but the site name would be instead of

If not owning a domain name, then accept URLs, such as or, which are fine too.

Even is a unique URL that is more in the open web than a public-facing Facebook page because Facebook annoys logged-out users with a large banner, encouraging people to join the network.

I visit blog sites who host at The authors don't care that they aren't using a domain name, and neither do I. I visit those sites for the content.


Pay for a virtual server and install web publishing software. Numerous small and large web publishing systems exist that can be downloaded and installed by users on their server accounts.

That's a geeky approach, which is probably beyond the capabilities of most non-techy people. It requires making security updates to the software and maybe tweaks to the code, which means acting like a sys-admin and programmer at times.

Or don't pay for a server and rely on free hosting services, such as those mentioned above. That way the security updates and software bug fixed are conducted by the hosting companies and not the authors.

Static vs dynamic site

A static site means that the web server serves up HTML files. Your site is not pulling content from a database, which would be a dynamically-generated page.

Static site generating software does not rely on a database, which means one fewer item that needs to be worried about, regarding security and uptime.

For static sites, the web posts are stored in text files on the file system, which can be easily downloaded for backup purposes.

Databases can be dumped for backups too. Databases make it easy to search content and to add dynamic features, such as a related articles section at the bottom of posts.

This debate applies mainly to users who buy server space and download and install a web publishing system. If hosting at Ghost, Medium, or Wordpress, then you don't have much of choice, regarding static vs dynamic.

If you host at GitHub Pages, then you will have a static site.

Your site vs social media

Publish on your own site first and then syndicate to your social media properties second.

Or publish on your own site and then to social media whenever and however. If you want to manually copy your social media posts to your personal site, that's fine. But if that's too much trouble or if you don't feel that it's worth backfeeding your social media content to your personal site, that's fine too. But lengthy text posts probably should be copied to your personal site too.

Follow the Indieweb principles or ignore them and do your own thing. The Indieweb concepts are technical and probably beyond most content producers. But it involves posting everything on your personal site, text, photos, replies, etc. and then programmatically, your content is posted to your chosen social media sites. The interactions on social media sites, such as likes and comments, are automatically posted back to your personal website. It's well-executed, but for many authors, it might be complex to implement and use. This might get easier with time.

The Indieweb evangelists increase every year, and they are committed to making it easier for content producers to own their content while easily interacting with their social media friends. The Indieweb began around 2010. Their inspiration is rooted in the 1990s and early aughts, but they are adapting to the modern web.


Design your website with a minimal HTML tag set from the early 1990s and no CSS and no JavaScript, or design your website as a JavaScript single page application that does not work if JavaScript is disabled.

Make your site serve static HTML files, or make your site serve dynamically-generated content.

Redesign your site once every five years or redesign every week.

Make each page appear differently if you desire. It's your site. Experiment and have fun.

Make your site's homepage display a stream of posts, ordered by creation date, youngest to oldest, or don't do anything close to this. Display any content that you want on your homepage. The top post could be from yesterday or from 10 years ago, followed by a post from two months ago, followed by a post from today.

Who cares except you. Maybe you order the posts on your homepage by YOUR favorites. Maybe your homepage is an "about" page, describing yourself, and your posts can be found in the archives section.


Create feeds in one or more of the following: RSS, Atom, JSON, and Microformats, or create no feeds. If the latter and if people want to read your content, they'll have to visit your site directly, instead of scarfing your feed in a reader app. If that's unacceptable to the feed-reading geeks, then too bad.

Most publishing systems produce at least one type of feed. The Indieweb promotes Microformats, which I find useful too. RSS is still heavily used.


Permit others to post comments on your site or prohibit comments by others. Same for the Indiweb's Webmentions, which I prefer over a comment system.

Webmentions forces commenters to create their replies on their own public-facing web presences or sites.

But it's not a requirement for you, the site owner, to permit others to post their content on your site. Commenters can post their replies on their own websites, and maybe you become aware of those replies and maybe you don't.

If you want, you can take your discussions to Twitter, or you can engage in no discussions anywhere.

It's probably easier for a beginners to publish on their own sites, and that's it. Don't even provide an email for people to use for replying.

Over time when beginners become more comfortable, then maybe they will enable some kind of reply mechanism. Again, the thinking should be a long, slow, organic process.

http or https

Use SSL/TLS with https or don't use it and continue with http. If people dislike your use of http instead of https, then they don't have to read your site.

Public or private

Make the site public to the world or private to yourself or to a few select people.

Type of site

Label it a blog, wiki, journal, diary, E/N (Everything/Nothing). It's called whatever you want to call it. How others label your site is irrelevant.

Make the content niche or post everything imaginable.

My site is a seasonal blog that runs from approximately from Nov 1 to Apr 1, and it covers winter weather in the Toledo area.

But will host my posts about weather, fishing, cycling, running, birdwatching, beer brewing, crocheting, art, sports, gardening, events, family, local politics, businesses, health, food, etc., etc., etc.

Boghop will host everything that means something to me even though it probably means nothing to everyone else. It's an E/N site.

What to write about? Anything.

"Even nothing is something."

Excerpts from with my additions surrounded by brackets:

GEORGE: I think I can sum up the show [WEBSITE] for you with one word: NOTHING.

RUSSELL: Nothing?

GEORGE: Nothing.

RUSSELL: What does that mean?

GEORGE: The show [WEBSITE] is about nothing [TO EVERYONE ELSE].

JERRY: But, even nothing is something. [ESPECIALLY TO THE WEB SITE AUTHOR]

GEORGE: What'd you do today?

RUSSELL: I got up and came to work.

GEORGE: That's a show [A WEB POST].