Given the recent censorship issues (not to mention crashing stock prices), the time is ripe for a twitter alternative. Sure it seems unthinkable right now, but let’s not forget the lesson of Myspace. Granted it’s not very probable, but it is definitely possible. For ease of discussion, let’s call this new service Blitter (unfortunately that domain name is already taken).

But before we start thinking about how to supersede Twitter with Blitter, let’s talk about what kind of features and functionality would be desirable. What follows is my initial thoughts on the matter and is not an exhaustive list – feel free to submit your own. This post is a work in progress and I’ll keep updating it as new features are discussed and determined.

#1 GOAL: Prevent censorship by changing the distribution model

Currently, Twitter.com is the central clearinghouse for all tweets. That allows them to be the sole arbiters of what is allowed/not-allowed, and they can censor whatever they want. So how can that be avoided?

Thankfully, we already have a model for non-centralized, distributed data dissemination – bittorrent. Could Blitter adopt a bittorrent-like design to disseminate messages?

The upside is that given enough non-filtering stream sources (trackers), no message/author could be censored. Also, the server-side requirements would be very low, making it very easy to stand up new trackers to handle demand.

The downside is that messages would not be delivered in real-time (near-real-time at best), and there are authentication and integrity concerns (addressed below).

This architecture presents some interesting design challenges, however. In order to provide efficient dissemination, I think most authors would have to sign up to a smaller subset of mega-servers which could aggregate messages together, and then those aggregates would be passed around to the smaller servers. So there might still be some centralization where one node going down could affect a large number of users – but at least there would be more than one. However this might be able to be addressed by having fallback publishing servers.

#2 GOAL: Provide authentication (author identity verification) while also allowing for anonymity

Given how quickly internet mobs can ferment and then hound individuals (get them fired, doxxing, harassment) for having a different opinion, we need to protect the anonymity for those who wish to remain safe.

But we also need to have some way to verify that a message came from a specific author and was unmodified.

Let’s address message integrity first. That’s another previously solved problem, we can use public/private keys (PGP style). A hash would be included with every message, which could be verified with the author’s public key.

So how does an author provide his public key? This is where authentication can also come into play. As part of the message, the author data would include an URL, which contains the author’s profile, which includes the public key. The URL will also act as another unique identifier for that author. The URL demonstrates that the author has control over a public site/page. So if I put my author profile on this site, I demonstrate that I am the owner of the site, and other Blitter users can verify that I am truly the author of the message.

By allowing author URLs to be published on any site that means that someone could have a site where they are anonymous, and then use the Blitter and still remain anonymous, but provide positive message authentication.

There then would probably be a secondary market for a service/site that provides hosting for Blitter profiles. Premium Blitter authentication services could charge more and do more thorough identity verification, and could therefore be more “trusted” than perhaps free (ad-driven) authentication services. Blitter could eventually include an authentication-site blacklist to inhibit bad actors, and while that’s akin to censorship, any coder could easily modify the software to ignore a blacklist if desired.

#3 GOAL: The protocol & specifications will be made public but not open source.

There will be a guiding body (either a dictator or committee) that has the final say over the protocols & specifications and will publish them for anybody to implement.

#4 GOAL: Reference implementations of the server (tracker) and client will be open source.

Since Blitter will be distributed, and there will be many servers online, the source code for the reference implementations of the server and client pieces will be made open-source.

However, that’s not to stop anybody from creating their own closed-source server or client implementations – just as long as they adhere to the published spec.

#5 DISCUSSION: How to prevent usage by criminals/terrorists to facilitate illegal activity?

Unfortunately because of #1, there doesn’t seem to be a way to prevent criminals or terrorists from using Blitter as a clandestine communication network. Then again, most of them already probably have several different techniques for that anyway. So I think this is a moot point. Perhaps Blitter secondary sites could provide information on known bad actors and the server or client implementations could use that information somehow. However, this could be abused for censorship purposes.

#6 GOAL: Facilitate (if not provide) private messages

Points #1-#3 demonstrate how Blitter can have public messages, but how can it do private messaging? Since all the messages are going across any number of servers, how can that even be possible?

The only way I can think of doing it is to encrypt the messages. In order to protect the anonymity of the recipients, the recipients cannot be referenced in the non-encrypted portions of the message. So if users wish to communicate privately they will have to provide each other encryption keys – so once again PGP should solve this problem. Blitter should however find a way to make it easy to exchange these keys. There could be different keys for different audiences (so instead of 1..1 private messages there could be 1..M private messages).

This feature definitely needs further fleshing out.

So what are your thoughts on this? I’d love to hear them.

Part 2 – brainstorming client/server communications.