Telegram is a great chat app, but there is more, and less to it, than say Twitter and Facebook. The first thing is that a lot of this gamification of likes/thumbsup is gone. Want to know if someone read your post? That has to be done either via direct message, or in a group (and the person has to respond). Recently there are new apis that help enable discussions on posts, as well as connecting channel posts as annoucements in groups.
Types of Accounts in Telegram
There is a single namespace in telegram for all entities: users, channels, groups, and bots. Users are individual accounts tied to a phone number (I think that is mandatory). Telegram Channels are one-way broadcast accounts, which can have multiple admins (but messages are signed by the channel. Membership in channels is unlimited. Telegram Groups can include up to 200,000 users, and everyone can post.
Using Bots for Commenting and Discussion
Note that for feedback on channel posts one can add a like botor other such simple feedback, or add a discussion group and put that information in the channel description. A third new option is to have a comment system using an app which would also be available on the web as a preview (without logging into Telegram). The preview bot that does this works nicely and shows off what kind of api/developer support Telegram.
No Manipulation or Advertising
Instead of the constant intrusion of 99% annoyance in terms of timeline distortion and advertising as found in Facebook and Instagram (and to some extent Twitter, which is going down that same path).
Essentially, the use of channels with comments can replace any given social network (other limitations apply), such as Twitter, Facebook, and Instagram. While those platforms still have the lion's share of engagement and users, moving over to the Telegram way of things makes sense.
Telegra.ph for Longform
Telegra.ph is a longform microblog platform which is very simple and also has zero advertising. There is a nice Telegraph App in the Google Play store.
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).
The challenge is to have an equally robust service that can effectively, and efficiently (regarding resource requirements) sychronize files across multiple devices. Remain on our own devices. And remain open source. In our case we have three different operating systems on four devices to support:
Android 7.1.2 (Nougat)
ChromeOS Dev distribution (using Chrome, Android, or Linux apps)
Debian Linux 9 (stretch) (server and desktop)
Options such as OwnCloud don't work because of the high overhead needed to get the services to work, in terms of memory and processing on a server.
Syncthing for File Synchronization
File synchronization is not backup, though with versioning there is a sort of backup-lite going on.
Syncthing is available from repositories and directly from Github. There are ports and other configuration issues to enable for routing. There is also an Android app, so that is what will be used on Android and ChromeOS.
Note that this includes Debian and Android apps for auto-on functionality needed.
Some Issues with Synchronizing
The main thing is to think out one's synchronization policies and plans. One-way synchronization, two-way sinchronization, master and slave device replication, etc. There are many options. Some files one will want to keep everywhere, with version control. Other files one will want only in one or two locations (large files/repositories).
The best approach is to partition into folders so that different folders contain different content that will be sychronized differently. Some examples:
Images/Photos folder on a mobile device
Should be synchronized but also allow for repository of more images on a backup location.
Workflow: sync mobile folder to desktop. On desktop, move images to a second folder (removing them from mobile via synchronization), and then have the second folder synchronized to a server. That server folder can have SFTP for remote access and also provide two-way synchronization back to the desktop for things such as editing images that are on a web server.
It is important to have a manual workflow as well (or semi-automated) so that things are easier to manage.
Synchronization vs. SFTP
Synchronization is useful, but is not a replacement for SFTP which should be seen as on-demand push/pull. For example, a large repository can be synchronized between two larger-capacity devices (e.g, Debian server and Debian workstation), but also allow access via SFTP for smaller-capacity devices (ChromeOS/Android).
Ultimately, Syncthing lets the enduser take full control over their data on their devices in terms of files that are synchronized with other devices. Along with SFTP on a server, and possibly something like AWS S3 and Glacier, it appears to provide a useful protocol, gui admin console, and applications that can do everything that GDrive/Dropbox/OneDrive offer in terms of synchronization. Since disk space is already something that can be managed at the level of S3/Glacier and local devices, it provide a key element in a resource-efficient, open source package.
Applying tidying principles of the Kon-Marie method makes perfect sense in terms of the digital landscape:
- Applications and Apps
- Email, Documents, and Media (Ebooks, Audio, Video)
The two stages of tidying are:
Discarding fairly straightforward: does this application, data, or media provide any spark of joy. One can't hold it in one's hand, but one can nevertheless reach a conclusion. In the case of mobile apps and desktop applications it is fairly straightforward. In some cases, necessity may posit the need to keep something around that is less-than-joyful but also might as well inspire a search for a more joyful replacement.
The basics of organizing are putting related things (category, size) in one location. Since digital things are not generally put away, it is the original location that is key (and finding things later).
Since files are sometimes best kept by file time (that is, so that programs editing those files can go to a single location, for a certain class of file). Example:
Which of the following is preferred:
In some cases where a given file may deal with more than one brand, then clearly the second is more effective, but in the case of a larger set of files for a specific brand, then the first is definitely a better organization.
Obviously both are possible, but it is important not to get too imprecise and flexible, as that generally yields only confusion and file disorganization.
Even given very large storage space, data and applications can clutter a device. Marie Kondo suggests that not the place of use but the place of return is most important (that is, give things a home that it is easy to return it to, rather than trying to optimize for where it is easy to pick up).
As mentioned above, storing things in easy-to-remember locations will be key, as putting things back into those locations (a digital file structure) will be very important. Visual clutter is still present when viewing directory trees, and is a significant failing in terms of Linux distributions and their file structures in terms of where applications and related data lives in logical drives.
Podcasting is growing (slowly) and offers a great opportunity for brand engagement. Generally free, the idea is to be where the audience already is, and have a reliable host for content and the rss feed.
This is meant to be a reminder of important issues/decisions that already have some thought put in them (usually by others).
- Automatic categorization of text is a core tool now
- Instead of offering advice, rank priorities
- Build a website first (before an app), some forgotten article but the point is: faster, and desktop users expect applications to work (and to pay for them). Plus if done correctly, this can work on all platforms (and then build the app for the appstore).
Stick with what we know in the marketing channels we know. Expand products, and channels for those products.
First, there are two kinds of DNS records: those for client look, and those for a server.
I don't trust Google DNS, though for a while it was the go to DNS, and easy to remember at 188.8.131.52 184.108.40.206 and 220.127.116.11.
For privacy, for me, there are two options, with the first being just better:
- dns.watch 18.104.22.168 / 22.214.171.124
- 126.96.36.199 / 188.8.131.52
If one wants some security (as a service), then Quad9 is worth a look.
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).
- DNSmadeEasy.com - Silly name, $30/year for 10 domains, fast and reliable. Generally in the top 10 of private resolvers. I've not found better/faster for cheaper.
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).
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.
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 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
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.
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:firstname.lastname@example.org"
- Name (host), Type: issue, Value: "letsencrypt.org"
I've written about WordPress at various points. I've been using this cms for 13-14 years, and for me it is well-known, though a bit worn out. The breakage it has has not improved much, and the resources needed are not up to the modern task. Essentially most performance gains are made through improvements in Nginx, PHP, and MariaDB (thankfully, and not inconsequentially). WordPress is a most dreaded platform for 64.5% of developers answering a developer survey on Stack Exchange. This beats out the core enabling technology dread levels of MySQL (50.4%) and PHP (58.6%). Simply put, WordPress has a premium dreadfulness to it.
For me it is time for the devil I don't know, rather than the one I do. Even with the Classic Press fork of WordPress, we are dealing with ossified technologies. Granted they will likely not die (the code base is too large), but that does not make them forever bankable and safe, as in the nobody got fired for using IBM of the past.
Automattic is the organization behind WordPress the content management system, wordpress.com, and a number of smaller entities. With some estimates, WordPress has ~30% market share of the web. It has taken on in excess of $300m in funding](https://www.crunchbase.com/organization/automattic) over the years. After 2–3 years of development of WordPress, Automattic was founded in 2005 to receive an initial funding round of $1.1m.
Competition and Growth
Competition is seen as foremost coming from the lower-end, simpler website design companies such as Wix and Medium. Basic usability and ease-of-use of the WordPress editor is seen as a stumbling block to growth, especially with investors who seek a return.
Matt Mullenweg, the co-founder CEO, is not shy to demonstrate the user problems, as seen in his most recent State of the Word presentation from 10 December 2018:
State of the Word — Matt Mullenweg — 10 December 2018
While there is an interesting solution provided in terms of Project Gutenberg and blocks to replace the wysiwig/code view editor, it in no way is an answer to novice users creating pages that have complex visuals (other than possibly copy-paste from Word or Google Docs).
More importantly, by removing the current wysiwyg/code view editing interface that all intermediate and advanced users have mastered, everyone is forced into a learning curve regarding these less-than-intuitive blocks. Certainly it is a mental model, as Mullenweg suggests, just not an intuitive one, or one that the interface makes readily apparent.
To allow for a transition period (aka Phase 2) the old editor will be available by means of a plugin, and has promised support until 2021.
The incipient integration of Gutenberg into Core caused quite a bit of disgruntlement, and induced action on the part of a group to do what is always possible with open source software, and to create a new release from the old source code.
ClassicPress, calmPress Forks of WordPress 4.9
Strengths can be weaknesses, and the open source software strength of WordPress has now been used against it in the form of hard forks of the project.
ClassicPress released its first version which is a fork of WordPress 4.9. Work began on this hard fork on 30 August, with alpha and beta releases on 24 October and 21 November.
calmPress, another fork of WordPress 4.9 is the effort of a single developer. calmPress 0.9.9 a fork of 4.9 was released on 29 November 2018, with alpha and beta versions starting back in September.
There was discussion about collaboration on a shared plugin directory between calmPress and ClassicPress, but that has not progressed.
ClassicPress Organizational Development
ClassicPress calls itself a business-focused release. That is, professional, stable, reliable performance. Already ClassicPress is undergoing some performance tuning and a focus on security. The main point is to dodge the bullet of Gutenberg, as with WordPress 5.0 that becomes integrated into Core.
Building a successful software project includes proper, effective guidance as well as resources (programming and money). From the ClassicPress forum and Slack channel, these discussions appear to be taking place, and developers are indeed doing the necessary, day-to-day, block-and-tackle efforts.
WordPress 5 Released
WordPress 5.0 was released on 06 December 2018. On 12 December WordPress 5.0.1 was released to include some security bug fixes. However, this also began to introduce breakage.
This is a Waterloo
The Battle at Waterloo has become a metaphor for something difficult to overcome, or recover from. With novices unable to easily adopt the new interface, and with a good swath of intermediate and advanced users in open rebellion against the change, there are now opportunities for sharpened knives. The forces arrayed against Automattic are as follows:
- Those who will defect to a hard fork (ClassicPress, etc., see above)
- Those who will defect to an alternate platform (Grav, etc., see below)
The main forces for Automattic are:
- User base inertia,
- Community that will censor defectors to a hard fork, and
- The WooCommerce and subsidiary plugins which make finding a replacement a more complex and time consuming task. (This is akin to trying to supplant Windows without having an alternative to Office.)
Troop Strength and Depth
While this might seem like a less difficult challenge than the fated Waterloo, the strength of Automattic's development ranks is thin and ragged. The ability to create quality code and a quality experience should be seriously questioned. For example:
- Two plugins remain in Core that cannot be touched (for the obviously irrelevant political reason that they were created more than a decade ago by the CEO), and lead developers have to resort to lying about it in the bug tracker. In ClassicPress, those two plugins were removed in the first Alpha release.
- The infamous WordPress plugin repository redesign fiasco of 2015–2017.
- Last but not least, the hostility to and distaste for Gutenberg to date.
If it were a matter of executing and providing a speedy and pleasent experience, then the rather steep learning curve could be mastered. Instead, the very same puzzling experiences found in user testing with novices using the current editor will be found writ large with not only novices, but intermediate and advanced users of the previous platform. As one reviewer put it I'm tripping over my own feet.
Again, it will take more than evangelism to win this battle because the quality of the WordPress package, including the ridiculous redesign of the Plugin directory and its functionality. This is not to mention, the antiquated development tools and processes that continue to cause WordPress, like an old jalopy, to rattle and shimmy down the backroads and washed out valleys of bloatland.
It is important to view another issue with WordPress which adds complexity and resource requirements, which for many sites is unnecessary: the requirement for a database. Flat file content management systems are increasingly functional and reliable and have significant advantages over the use of a database.
Databases are generally opaque, more difficult to inspect, require their own backup and restore procedures, have their own security, use more resources (specifically ram, but also processor) and with advanced caching readily available, do not have much in the way of benefit. For special uses such as shopping carts and session management, a database can be used as a supplement to a Flat File CMS, but for serving most content, it makes little sense.
Grav CMS, a maturing Flat File CMS, is a viable alternative to WordPress for certain use cases, perhaps even the majority (and has shopping cart plugins available).
For those developers, administrators, and endusers, like me, who have spent more than a decade with WordPress are are looking for a platform for the next 10 years, Grav looks quite promising, as does ClassicPress. WordPress? Not so much.
Content Management Systems come in all shapes and sizes, and it is unfair to evaluate their maturity based on their functionality. However, to some degree this is still a useful metric, depending on the fucntionality. Below are hallmarks of functional maturity. Again, certain CMS's will not receive an accurate score based on specific niche uses or unique aspects.
- CLI / command line interaction
- Various caching options available
- Ecommerce-friendly/Ecommerce package(s) available
- SEO metadata friendly
- Email/Form management
- Effective templating system
Widespread caffeine use explains a lot about the twentieth century.