Back in 2012, I looked at the concept of peer-to-peer blogging. It is definitely time to revisit
the environment.
Back then, the main threat I was concerned with was state action directed against service providers being used for copyright infringement. Since then, my political views have become more extreme, while the intolerance of the mainstream left has escalated alarmingly, and so the main threat today is censorship by service providers, based on their own politics or pressure from users and/or advertisers.
Actually publishing content has become easier, due to cheap virtualised hosting and fast residential broadband, making a few megabytes of data available is not likely to be a problem. The difficult bit is reaching an audience. The demise of Bloglines and then Google Reader has been either a cause or a symptom of the decline of RSS, and the main channels for reaching an audience today are facebook and twitter. I don’t actually use facebook, so for me twitter is the vital battleground. If you can build up a following linked to a twitter ID, you can move your content hosting around and followers will barely be aware it’s moved. Last week’s Chuck Johnson affair defines the situation we face. We require a robust alternative to twitter—not urgently but ideally within a 12–24 month timeframe.
I’ve been running the Twister peer-to-peer twitter clone for a couple of weeks, and I think it is OK.
Primarily, it is built on top of the bittorrent protocol. Messages are passed from node to node, and nodes collect messages that are relevant to them.
In addition, it uses the bitcoin blockchain protocol. This is not for content, but for the ID database. Content published by an ID must be signed by the key associated with that ID, and the association of keys with IDs is made via writing entries into the blockchain. Ownership of IDs is therefore “first come, first served”, with the ordering of claims determined by the blockchain (just as the order of transaction attempts is determined for bitcoin, preventing double spends).
As an incentive to build the blockchain, each block can include a “spam message” which will be presented to users.
What that means is that there is no authority who can disable a user ID or take it over. If the ID is registered on the twister blockchain with your public key, it is yours forever.
The application runs, like the bitcoin reference client it is based on, as a daemon offering a JSON-RPC socket interface. It also serves some static web pages over HTTP on the same port, providing a working twitter-lookalike web client.
As far as I can see, it works properly and reliably. I am running it over Tor, and that works fine.
Current Shortcomings
It’s still treated as experimental by the authors, so it’s not surprising if it’s not complete.
The biggest shortcoming is that it’s inconvenient to run. Like bittorrent, it needs to find peers and build a network to exchange data with, and, like bitcoin, it needs to keep up with a blockchain. (It is not necessary to “mine” or build the blockchain to use the service). You really need to start it up and leave it running, if not 24/7, at least for hours at a time.
For the same reason, it doesn’t run on mobile devices. It could be ported, but staying on the peer-to-peer networks would be an inconveniently heavy use of data, battery and processor resources.
Fundamentally, you don’t see all the traffic (that wouldn’t scale), so you can’t conveniently search it. You need to advertise that you are interested in something (by following a user, for instance), and gradually it will start to flow your way.
Future Shortcomings
The network is currently very small-scale, so it remains to be seen how well it would scale up to a useful size. I don’t understand the torrent / DHT side of things all that well, but as far as I can see it should hold up.
The ID blockchain functionality seems more reasonable. If each new user requires of the order of 64 bytes of blockchain space, then ten million users would need about a gigabyte of disk space to archive. A lot, but not prohibitive. As with bitcoin, the hope would be that users would be able to use lightweight clients, with the heavy network functions semi-centralised.
[The useful feature of a peer-to-peer protocol for us in this scenario is not that there is no trust in the system at all, or that there is no centralisation at all; it is that there is no single thing that must be trusted or relied on. The user has the option of doing everything themselves, and, more useful to the ordinary user, they have the option of temporarily and conditionally trusting a provider of their choice]
Also as with bitcoin, the most difficult obstacle is key management. When you want to start using twister, you generate a key pair, and post a transaction associating your public key with your chosen twister ID. You need the private key to post twists, or to see private messages. If you lose the key, you’ve lost your ID. If someone gets your key, they can post as you and read your private messages. Handling keys securely is difficult. For a casual user who isn’t too concerned about surveillance or censorship, it’s prohibitive.
Like bitcoin, the network node, blockchain archive and wallet (user ID) are all managed by a single process. Logically, the private operations of creating authenticated transactions/messages ought to be separate from the maintenance of the network node.
Twister is designed for those who are concerned about surveillance or censorship, but we need to be able to talk to those who aren’t. It needs to provide security for those who need it, while being as easy as possible for those who don’t.
The system seems fairly robust to attacks, including denial-of-service attacks. Media companies have attempted to interfere with bittorrent, but have not as far as I know blocked an actual running torrent, rather concentrating on the chokepoints of communicating knowledge of specific torrents.
The ID subsystem could be flooded with new id requests. There is a proof-of-work requirement on individual “transactions” (new id assignments), separate from the actual block proof-of-work, but that cannot be too onerous, so a determined adversary could probably produce tens of thousands. However, miners could respond by being fussier about what they accept, without breaking the protocol.
The blockchain itself is vulnerable. The hashrate at present is about one quarter-millionth of Litecoin’s (which uses the same hash method), so one block of the twister blockchain currently costs about the same in compute resources as a thirtieth of a cent worth of Litecoin. (I have mined dozens of blocks myself over the past week). Anyone with a serious GPU-based mining rig could mine hundreds of blocks in minutes. The incentive for legitimate miners is always going to be weak, since a customised client can trivially ignore the “spam” messages. However, it does not seem obvious that that is a real problem. The value of the blockchain is that it established ownership of IDs, but an ID is not really valuable until it has been used for a considerable period, so to take over a valuable ID, you have to fork the blockchain from a long period in the past. Even if you have the hashpower to do that, your blocks are likely to be ignored simply by virtue of being so old.
Suggested Enhancements
The main author has suggested taking the cryptography out of the daemon and into the web client (in javascript). That would be an improvement and a step towards usable lightweight clients.
However, there is another requirement to do that, which is more sophisticated key management. Mobile devices and third-party service providers would hugely improve the convenience and usability of the service, but at a cost of crippling the security, since neither one is sufficiently trustworthy to hold the private key.
What I have suggested is a system of subkeys, with restricted delegated authority. I create my key pair and post it to the network with my chosen ID, as per the current protocol. Then, I can create a new key pair, and create a transaction signed by my original key (which I call the “master” key), delegating the authority to make posts for a limited time (a week, say) to this new key (which I call a “subkey”). I transfer the private key of the subkey to my phone app, or to a service-provider I trust, and can then make posts using the subkey.
After the week, that subkey is expired and posts made with it will no longer be accepted as valid by other clients or network nodes. If the key is compromised, the damage is limited. I could even post a “revoke” transaction signed by my master key.
Alternatives
@jokeocracy has pointed at Trsst. Also, GnuSocial is quite well established. Both of these are federated client-server architectures. See quitter.se as an example GnuSocial-based service provider. (It would be funny if we were to all move en bloc onto some lefty-oriented “free from capitalism” platform, and perhaps instructive, but not necessarily a long-term solution).
There is some resistance to censorship there, in that if one service provider blocks you, you can switch to another. However, your persistent ID is tied to the service provider you choose, which could take a dislike to you or (equally likely in the early stages) just go away, so it makes it harder to maintain continuity. Also, the federation model does not necessarily prevent the consumer’s service provider from censoring your messages to its customers. The customers can switch if they want to, but not trivially.
In the case of Trsst, it strikes me that this is a mistake: users have private keys, but the association of keys to IDs, unlike in the case of twister, is made by the service provider. If mentions, replies, and subscriptions were by public key instead of by “nickname”, users could migrate more painlessly. However, that registry would have to be distributed, adding complexity.
In the long run, what I would hope to see is a service that looks like quitter.se or Trssst, but acting as a proxy onto the Twister network, ideally with short-lived subkeys as I describe above.
Other relevant projects not ready yet would are Urbit (of course), and chatless (by @_raptros).