Ten Forward

One of the many requests people have made recently is support for shortcodes that will be seen as emoji when published. This allows people who are using desktops or devices that do not have an emoji keyboard to use the fun little images. For the first release of this function, I've decided to stick to 30 of the nearly 1,000 emoji¹ that are available. Should the feature prove to be popular, I'll slowly grow the set of shortcodes to include things like :badminton racquet and shuttlecock:.

Using the shortcodes is pretty easy. Simply put a colon on both sides of the code, and consider it done. Below is a list of the first 30 shortcodes supported by 10C:

• :coffee:
• :tm:
• :copyright:
• :registered:
• :banging:
• :interrobang:
• :sunny:
• :cloud:
• :umbrella:
• :point_up:
• :relaxed:
• :warning:
• :zap:
• :soccer:
• :snowman:
• :baseball:
• :airplane:
• :partly_sunny:
• :envelope:
• :fist:
• :v:
• :raised_hand:
• :heart:
• :star:
• :jp:
• :uk:
• :it:
• :kr:
• :ru:
• :us:

If the icons aren't looking quite right on your screen, it could be for any number of reasons. Unfortunately, some operating systems don't want to use the Unicode emoji codes and instead have their own way of rendering them.

Want to see some specific shortcodes? Just send me a Blurb.

—

1. As of this writing, there are just over 800 "recognized" emotion characters, though many operating systems support fewer than half. This can make for one heck of a problem when trying to better express ourselves in our writing.

One of the many features that people have requested over the last few weeks — including me — is the ability to have our blog posts "automagically" appear as a Blurb when they are published. Seeing as how these things are hosted on the very same network, there's no reason why this can't happen. There were a few issues that needed to be worked out, such as what to do with regards to blog posts or podcasts that are dated in the future or past, and items with different visibility permissions or post expirations set, but a preliminary version has been released for people to try out.

A new button has been put under the Files box next to the Publish button. This is, for the moment, set to send Blurbs by default. Of course, it can be clicked to shut off the feature. Another future update will allow people to have this button set on a per-site basis.

Future updates will see the Auto-Blurbing become much better, with post summaries being published as well as images. Podcasts should also have the audio file posted and, naturally, listens through the Blurbs will count as downloads in the creator's stats.

Have a feature request? Just get in touch!

Over the last few weeks I've been thinking about a problem that is not at all new, not at all solved, and one that I am cognitively struggling to solve. 10Centuries is a platform that I've built the last few years to solve some of the very important problems that we face when it comes to storing information online. Matters such as data degradation, link rot, and digital permanence can be reduced as the people who host online services typically have a backup and restore strategy that is tested and proven sound to quickly recover after catastrophic failures in hardware or software. This is great as the typical person rarely ever thinks about the problem of data loss until their data has been lost. At 10Centuries, automated processes are in place to make sure that information is very hard to lose. Backups are automatically tested moments after being created, and files are verified to ensure the copies are always exactly the same as the originals. This isn't the problem that I'm thinking about, though. The issue that I'm struggling with comes down to one word: trust.

You need to trust that my services are living up to your expectations. You need to trust that I'm not going to lose your information in the event of a server failure. You need to trust that the posts that you've deleted or expired are actually gone from the servers … but how?

Digital Receipts?

Trust is a very delicate thing. It can take a long time to earn, and just a split second to lose. When something is marked for deletion on the 10Centuries platform, a few things kick into action.

For text-based information, any content related to the post is immediately scrubbed from the server, including the metadata which includes things like post length, publication dates, and the like. Any files associated with the post are left intact in an account's storage in the event it will be used again in the future.

When files are deleted, they're immediately removed from the main server. The backup server, which keeps a "hot copy" of the files in case the main storage area fails, is sent a message to delete the files and the action is carried out almost immediately. I've been testing this quite a bit over the last few months, and the system appears to be pretty solid.

When entire sites or accounts are deleted, the first thing to go is the text, and then the files. The entire process, as of this writing, is typically completed in about 0.5 seconds across the entire 10Centuries platform.

But what about backups?

10Centuries has a very strict backup regimen. The main servers run in Japan, with some being in Tokyo and others in Osaka. A virtual server located in Vancouver has a copy of the database and the files in the event a huge earthquake turns the entire country of Japan into a modern-day Atlantis. Backups are made from the Vancouver server and stored both in Japan and Canada. The servers that keep the backups are only used for this purpose and test the data upon receipt. Backups that fail to open or restore information are discarded and a new backup is requested. These files are cycled every 7 days. This means that 10Centuries never has deleted data for more than 7 days in its system backups, which is all well and good … but how do I prove this?

As the service grows, this question will become more and more important as people will rely on deleted content to be gone just as much as they rely on existing content to be available at a moment's notice. We know from past experience that some web services do not actually delete anything from their database when they claim to and, unless that service is Facebook, this can cause a painful backlash from people around the world. What we need is a verifiable way to show people when data is deleted from servers … but how?

If you have any suggestions or ideas, I'd love to hear them. Get in touch!

Have you ever sent an email that you later regretted? Have you ever drunk-Tweeted a picture that later got you in trouble? We all have our moments of poor judgement, but it doesn't mean we should be haunted by the evidence everywhere we go. Despite the ultimate goal of 10Centuries to keep information online for, well … ten centuries, people should have the ultimate say in how long their information remains online. For this reason, every piece of information that you upload to the network can have an expiration date attached to it. And, starting today, expiration dates just became a whole lot simpler with Blurbs.

Previously, expiration on Burbs worked the same way as it does on other types of information, we'd have to enter a hard date and time in YYYY-MM-DD format, and it was just ripe for misunderstandings and mistyping. So, to make things easier, we now just need to put in the number of hours a post is visible for. Any number greater than zero is accepted — including decimals.

So go ahead! Shout into the void if you feel the need. Just rest assured that, unless someone takes a screenshot of your incriminating Blurb, nobody will see it after the visibility period times out.

One common issue that people have lamented over the years on Twitter and App.Net is the inability to do much with favourited posts. The verbiage can also come across as wrong depending on the content of a given post, as we would never want to "favourite" or "like" a post that has a link to an abuse support group or something else that we want to save for later. There's also a problem where a single verb cannot fully encapsulate why we are trying to save a given post for later. Am I favouriting (or starring or liking) this post because I love the pictures displayed? Am I favouriting (or starring or liking) this post because it has a link to a news article about H5N1 bird flu that I want to read later? These are very different things!

When the concept of Blurbs was being flushed out, one of the problems I wanted to solve was the ambiguity involved with the various interactions a person can have with a post. It's completely possible to star a Blurb on 10Centuries, just like we can see on social networks across the web. But there's another function that might prove useful to people, and it's available to everyone as of today: Pins.

Pins are a way to save and organise posts for later use. Just like the physical object they're named after, these Pins come in several colours an can be used to mark a post (or any object, really) for later. There are, however, some distinct differences between Pins and Stars or Reposts.

The first difference is that Pins don't come with a pre-defined notion of meaning. You can use a colour coding scheme that makes sense to you, and nothing in the system will tell you otherwise. The second difference is that your Pins are invisible to everybody but you. Stars and Reposts are openly visible to everyone, including the person who published the post. Pins, however, are private. This will reduce any stigma one might have by using pins of a certain colour. More than this, though, it's nobody's business to see what you're pinning for later or how you organise your colours. Some things are just better off private.

Pins are quite easy to use. Just like with Stars and Reposts, simply tap the Pin icon on a Blurb to open a window of coloured Pins. Choose the one you want, and that's that. The Blurb's Pin will automatically switch to that colour. Want to change colours? No problem. Simply change it to whatever other colour you prefer.

As I said up above, Pins are now available to everyone who is using 10Centuries v4. Enjoy!

Happy 2016!

This year is starting with a roar as the v4 update to 10Centuries is finally entering its Beta Testing phase. One person is having their new podcast hosted from the platform, and the feedback has been invaluable. There's only so much a person can do when building something in isolation, so when other people join in the testing and share their observations, good things can happen. This is what we're seeing with 10Centuries.

Now, it has been quite a while since I've given regular updates on the development of the 10Centuries platform. I'm hoping to fix that with this blog right here, and with some other exciting things that are in the works but not yet released. What I can say, though, is that I'm still on schedule for a limited release by April of this year.

What do you mean, "limited release"?

With the plethora of blogging and social tools out there right now, there won't be a great demand for 10Centuries. Heck, this service is four years old and it's still small beans compared to just about every startup that launched last week! The service currently serves about a million page views a week across 1,820 sites, and this is an impressive number. What I'm hoping to achieve with the v4 software update is to bump the number of weekly page view up to 10-million across 5,000 sites with — hopefully — 150 paying subscribers. As everyone knows, web servers are not free, and I'd love to ensure a steady income to keep the machines up and running. Since launching in 2011, 10Centuries has been 70% funded out of my own pocket. I'm okay with this, as this is my project. But it would be nice to give people a reason to upgrade to a $12/year account.

But how?

Starting from April (and maybe earlier), 10Centuries will be an invitation-only service. People with Standard or Premium accounts and who currently use either v2 or v4 will be able to send invites to 5 people per week. These people can join for free and get full access to the system. There will be some storage limitations in place, of course, but everybody will have full access to the resources in the network. Hopefully, by seeing what 10Centuries can do, people will be encouraged to upgrade to a paid account and contribute towards the longevity of the project.

10Centuries is, after all, a 1,000-year project.

Over the coming weeks, I hope to write more about the various reasons people will have to upgrade and, hopefully, you'll agree that the service is indeed worth a dollar per month if not more. And why shouldn't it be? 10Centuries will keep your information online long after all of the current popular web services cease to exist or evolve beyond what you want them to be. The service may be small, but it's going to remain focused on this singular goal.