Posted on Leave a comment

Domain Registrars, DNS, VPS, Hosting

Simplicity is a wonderful thing. For the domain name game and hosting services, there are two kinds of simplicity:

  • A single, monolithic simplicity - aka all-in-one
  • A set of modular simplicities - aka best-of-breed

At this stage in web hosting, domain name registration, and DNS service offerings, the second form of simplicity is the preferred approach to dealing with domain registration, DNS service provision and hosting service providers.

Three Services - Three Service Providers

The current approach we take is to manage service providers at each level of service provision: domain registration, DNS services, and hosting providers. In addition to hosts (actually, unmanaged VPS or cloud services), there are application providers (SAAS/Cloud Apps), such as Google Apps for Domains (including the venerable Gmail/GoogleMail as well as their cloud/web-based office suite).

Domain Name Registration

  • They register and manage the domain nameserver pointers (NS records) that are registered with the 13 top level DNS servers
  • The customer indicates and can change which nameservers to use, based on who the preferred DNS service provider is
  • Cost is approximately $10-35/year/domain (depending on TLD), with per year or multi-year registration
  • Our preferred Doman Name Registrar is currently Porkbun, though I tend to change these every few years when service levels decline and prices increase.

DNS Service Provision

  • They manage the servers and record entries which point to various services that are hosted at various addresses, including email, web, ftp, jabber, etc.
  • The customer can create and change all the various entries to point to different servers or service providers depending upon what application hosting services they have with service providers (email, web, etc.)
  • Costs should run about $5/month on average, for around 10-20 domains
  • Our preferred DNS service provider is DNSmadeEasy which is $ 60 USD/year for 25 domains (even cheaper for 10 domains), and $1.95 per domain thereafter.

Application Hosting Service Providers

  • They manage one or more of the servers which offer particular services, and provide client management interfaces
  • At this level, each application can be considered a unique offering which then uses the best-of-breed approach at a finer level, which enables the use of individual service providers for each service needed, such as email, web, application development, etc.
  • The customer then can individually manage the configuration and content delivered by each given application
  • Cost is from $0 to $200/year depending on service.
  • Our preferred email, chat and cloud-based document sharing and collaboration service provider is a roll-your-own system based on Syncthing, iRedMail, AWS SES, AWS Lightsail, and if needed Amazon Workmail.

Unmanaged VPS Provision

  • AWS is our current VPS of choice, especially Lightsail.
Posted on Leave a comment

Syncthing = Dropbox & GDrive Alternative

Syncthing

Google Drive (GDrive) and other cloud storage alternatives such as Dropbox and Microsoft Ondrive all have the serious drawback of keeping one's information in a third party cloud repository. Privacy and security are generally compromised this way, even when paying for storage (as opposed to having an advertising model, which is worse in many ways).

Continue reading Syncthing = Dropbox & GDrive Alternative

Posted on Leave a comment

Pandoc, Markdown, XeLaTeX, EPUB

EPUB documents are essentially a kind of html document as a collection of files which are zipped, and include html, css, images, and some XML pages. There are several ways of organizing these, but the most straightforward is one html document for each chapter (or section), a set of images organized in a subfolder, and a few metadata files regarding the collection. An epub document can be even simpler, and consist of a single html file, no images, and a few metadata files.

Continue reading Pandoc, Markdown, XeLaTeX, EPUB

Posted on Leave a comment

Image / Scaling / Compression

Size matters, and the smaller the better, when it comes to generation, modification, transmission, and storage of information. The vast amount of unoptimized documents and images on my very own local storage, much less what we send and receive all the time, is astounding. The idea that we need 100gb or 1tb of storage (thank you Dropbox, not) is sheer waste and sloth. I've addressed these issues a bit in the past, but it is time to take a bigger picture approach.

Note that this refers not only to images but essentially collections of images, namely pdf documents and video.

Continue reading Image / Scaling / Compression

Posted on Leave a comment

DNS Records and Services

First, there are two kinds of DNS records: those for client look, and those for a server.

Client Lookup - DNS Resolvers

I don't trust Google DNS, though for a while it was the go to DNS, and easy to remember at 4.4.8.8 8.8.4.4 and 8.8.8.8.

For privacy, for me, there are two options, with the first being just better:

If one wants some security (as a service), then Quad9 is worth a look.

It is possible to run one's own resolver, though it takes a bit of configuring and resolvers are seen as an attack vector for various bad actors.

DNS Services

There are several DNS services to choose from. Dyn and related companies is the worst. Free DNS services such as afraid.org and he.net are unreliable, or simply not reliably fast. It makes the most sense to go with a top-rated DNS service (highly available and fast resolve times), and pay for this service (though less is more when it comes to expenses).

As with resolvers, basic DNS services can be run on one's own server, not including the Registrar functionality of placing the nameservers in the root domain servers of the Internet. Again, it takes a bit of configuring so that one has functionality, privacy, security, and is not seen as a target.

DNS Records

NS Records

There are several records to worry about. The first are nameservers, which are put into the registrar database. This can be as few as two or as many as six (possibly more).

A Records

Depending on the DNS Server, these can have wildcards or not. Generally there are at least three A records to have:

  • Root domain
  • www subdomain
  • * wildcard

For certain services, it is required to have a www. and also people mistype this, so it is best to have it as a domain, to have it on the SSL certificate, and to have a reroute from www. to the root domain.

CNAME Records

Usually only Bing Webmaster Tools requires a CNAME record. Otherwise these are generally worthless.

MX Records

These are for the mailserver. Usually a few are needed, one plus two backups. Gsuite has five records, but that is overkill. The top three make the most sense. Also, there are priority numbers, e.g, 1, 5, 10 to govern the round robbin-style resolving.

  • 1, aspmx.l.google.com.
  • 5, alt1.aspmx.l.google.com.
  • 5, alt2.aspmx.l.google.com.

TXT Records

TXT records are the go to place for every third party to put their info. Several examples of TXT Records include:

  • Yandex Webmaster Tools validation
  • Google Webmaster Tools/Analytics/GSuite/etc. validation
  • _acme-challenge records for DNS-based authentication for LetsEncrypt

PTR Records

PTR records are essentially a reverse so that an IP address is associated with a host.domain.tld. This is key for sending email.

DKIM, SPF, DMARC

These are all records for email security, at various levels. DKIM and DMARC are TXT records, and SPF can be TXT or specific SPF records, depending on the DNS service provider.

SPF Records

SPF looks like:

host.domain.com / "v=spf1 include:_spf.google.com ~all"

SPF are one of the earliest and easiest email records to set up for security, and specifically states which hosts can send email for the domain.

CAA Records

These records help tell SSL Cert providers which of those providers can generate a cert for the domain records. Each host needs two records:

  • Name (host), Type: iodef, Value: "mailto:address@domain.com"
  • Name (host), Type: issue, Value: "letsencrypt.org"
Posted on Leave a comment

Open Source Cloud

The day has come when I have confidence it is possible to move off of all third party clouds, with the only exception being social media and social network sites. That is, the wonderful world of email, file sharing and synchronization, and even online document collaboration, can all be supported independent of third party services.

Desktop Applications - Open Source Replacements

Around 2005 I decided to move off of all possible proprietary third-party applications. This has been largely successful, though there are a few smaller tools I do pay for. In those days the two monsters were (and still are) Microsoft and Adobe.

There are many additional tools which have been overcome by their Open Source rivals, especially with the trend toward lightweight.

Cloud Applications - Open Source Replacements

In terms of the cloud, the heavyweights are Google Docs/Google Drive and Dropbox. Of course there are other tools out there which are equivalent (essentially, web-based document editing/sharing and file synchronization and sharing tools). And not to forget, the venerable mail and calendar tools.

So what we need are:

  • An email, calendar, contacts application with webmail functionality (and underlying email transport) -- iRedmail has become an attractive platform since it integrates other well-known tools.
  • For file synchronization, Syncthing works well.

For some kind of shared document collaboration in the cloud, there are options but the big problem comes down to security/privacy (for third-party services) and functionality/maintenance (for self-hosted solutions).

For third parties there is Cryptpad, and self-hosted versions available from their Cryptpad Github repository.

Posted on Leave a comment

How to Ditch Google Email

This is really about how to get off of Gmail/Google Email for Domains/Gsuite. It is not difficult to get off of Google Drive, and Google Photos, as well as Google Docs and Google Sheets, and the like. But there are certain advatages of Gmail/Google Mail, and the free version of GSuite, which I've been using for ten years or so.

Continue reading How to Ditch Google Email

Posted on Leave a comment

The Problem with H1

H1 and Content Boundaries on the Web and EBook Publications


NOTE: H1 isn't really a problem, the thing is that it defines a chapter, not a work (though a chapter could be considered a work in the sense of songs being considered works that are part of a collection). H1 is a problem when using a Markdown Lint and concatinating all chapters into a singe document (which makes more sense than one might think when working in tools such as VSCode).


There is a problem embedded in epub, which is that it is normally composed of several html documents, one per chapter. However, for parsers to create epubs properly (such as Pandoc), they do it based on H1, so that each H1 signifies the beginning (and title) of a new html document (which is a chapter).

However, as we know an HTML document itself (especially regarding the web) should only have one H1. Therefore if the native (single) document being edited is itself a book, then the single document will have multiple H1s embedded within it.

This means there is a basic disconnect of a book being an ODT file or HTML file or even a PDF vs. being an Ebook.

Baker & Taylor require epubs to have only one H1, which is itself the title of the work, and everything else H2 (e.g., chapter headers). However, the spec and common use has an H1 for each chapter.

See:


Pushing the problem from H1 to Meta Title gives the same problem: An epub ebook has multiple html documents (one per chapter). On the web, there should be one and only one H1 (for Google's purposes, and possibly in the HTML spec). The Meta Title is not (necessarily) displayed to the user (though browsers traditionally put it into the browser title bar as well), whereas the H1 does get displayed to the user, so these definitely have two different uses in terms of user/display.

The problem I see comes when people what to explicitly tag H1, H2, etc., and your application decides if/when it will do overrides. This is (partially) what I mean by having semantics (markup via markdown/copymarkup) be primary. By not having this and dealing with HTML export/native file format, you put all the control into your application, but take it away from the user and the documents.

Further, I believe that documents themselves should not be the top level, but collections of documents (libraries).

What this allows for is people to have a single editor instance and navigate across multiple documents, books and book elements. This is very fast when wanting to bounce around between various documents. Granted it can slow down on load and save if the entire structure is written out.

This helps further define things such that a book is not a single document, but a collection of documents (the idea of "book" being a container). Not only does this work with epub thinking but also website thinking. A website is a collection of documents, but not a document itself (it is an address). Also, this idea helps out that each web page itself has an address, as well as meta title and h1. In essence this means that a web page is a chapter in a web site (book).

This means that epubs and websites are on the same page, as it were, whereas the pdf and odt is (or rather, can be) at odds insofar as a single instance can be a collection of chapters (and accompanying images, including usually a cover image).


Note that in a collection, if the Title of the collection is an H1, there is still the problem of each working having either a single H1 or multiple H1s. How to parse this as a tree is interesting both in the production of Epubs as well as PDFs. For a multiple-document (book) collection, with a generated ToC, there are many possibilities, such as:

  • Title Page (hidden, unlisted, unnumbered)
  • Copyright (hidden, unlisted, numbered)
  • ToC (hidden, unlisted, numbered)
  • Preface / Introduction
  • FIRST BOOK
    • Title Page (hidden, unlisted, unnumbered)
    • ...
  • SECOND BOOK
Posted on Leave a comment

Paypal vs. Stripe

Paypal Sucks

Paypal sucks, as everyone knows. It has one benefit for the consumer (those buying with paypal) and that is their dispute resolution, which I've used perhaps ten times and have never lost. Dispute resolution with credit cards and banks is much, much more difficult and harder to win.

For the seller, however, Paypal is horrible. Their rates are higher, their exchange rates typically add on 5%, and they also have fees for transfer to one's bank (in Thailand that is now 50 THB, though it used to be free for transfers over a certain (small) amount.

Stripe - A knight in shining armor

Stripe is the great competitor. It is available in far fewer countries than Paypal, but where it matters such as places like Vietnam, India, and the Philippines, Paypal is still largely unavailable for use. Stripe is avialable in India but only Malaysia and Singapore in terms of Southeast Asia. That said, Stripe has a way to enable those operating in countries without support to be fully functional, and that is by setting up a US corporation and enabling ease of banking setup. This service is called Stripe Atlas, and is in fact so much better than anything Estonia is marketing under their misguided and mischaracterized e-residency, which is neither a residency nor any kind of incorporation or accounting infrastructure (basically a chip on pin ID that works poorly, if at all).

If we look at fees for an organization working out of Thailand (that repatriates funds in Thai Baht), here are some numbers:

Example: 3 transactions of $33 USD/month

Paypal fees

$ 5.25 transaction fees
$ 5.00 currency conversion fee
฿ 50.00 bank transfer fee (~ $ 1.75)

Total: $ 12.00 USD = 12 %

Stripe + Transferwise fees

$ 3.78 transaction fees
$ 0.24 currency conversion fee (mid-market rate)
฿ 69.00 bank transfer fee (~ $ 2.20)

Total: $ 6.22 USD = 6.22 %

Note that the Stripe transactions scale much better as the currency conversion fee is fixed unlike the Paypal currency conversion. In addition, as we see the Stripe fees are lower for any given transaction.

Other reasons Paypal is worse than Stripe

  • Paypal transfer payments take a long time. Of course for no good reason other than that Paypal wants the use of other people's money for longer (4-7 business days in Thailand).
  • Paypal doesn't deal with Transferwise or Payoneer banks, and refuses to send/receive money to them. No good reason here, other than seeing these fintech companies as competition and making their customers suffer for using them.
  • Paypal technical support/customer service is notoriously poor.

Resources

Posted on Leave a comment

WooCommerce Paypal Settings

Updated July 2019 - I no longer use Paypal, as it is roughly twice as expensive as Stripe when looking at $100 USD/month in transactions (more than 10% with transaction fees and currency conversion), and without currency conversion it is still 30% more when only looking at transaction fees (usually because of the international transaction fees which are higher). If one is not a US national or without a US company, then use Stripe Atlas to incorporate and get banking set up.

There are several areas within the Paypal site and Woocommerce settings tabs that need to be configured to get everything working properly, including auto-return, IPN notifications, etc.