Txt is a little word processor that keeps your work safe with
It is very nearly in Alpha!
git clone firstname.lastname@example.org:shibacomputer/txt.git txt cd txt 📦 npm install 🔨 npm run rebuild 👉 npm start ✨ 📝 🚀!
This will install everything you need to build Txt successfully!
I can't stress this enough. This needs a lot of work, the code needs a huge cleanup, I need to write tests and it needs other eyes on it.
Why make this?
One day, I got sick of using Day One as a journal. For me, intertwining my text output with an external subscription service didn't feel right. Instead, I wanted something with a small set of features, that ran locally and that I could trust. I started drawing up some designs, and a year or so later, here we are.
And as it turns out, many people think the idea of working with small, encrypted text files very compelling.
Txt is an opinionated statement on the relationship between personal work, data management and interaction. At time of writing, Txt is the only word processor that offers simple collaboration, document versioning and contact management implemented as such that it can run off of 1 or more USB sticks, or on public infrastructure, whilst offering the same UX on any system - including a live Tails install. In my considerations designing and building this, I'm trying to make sure it's really useful on a day to day basis without any sort of platform lock in. So long as you have access to the key, all Txt documents can be retreived without the app.
The beta focuses on text entry, but 1.0 will include image embeds, management, document histories and a few other features. We'll see where this goes from there.
Choosing GPG encryption and the filesystem as the app's foundation is deliberate. Rather than build a database, Txt relies solely on the filesystem. Anything you make with Txt can be read and reviewed somewhere else. On computers that are already set up with GPG, your work is accessible at a system level if you add the key to your GPG keychain. There is no import/export library tool, because adding one would be redundant. Everything used is off the shelf.
I am very grateful for both design and development contributions, as well as bug reports and feature requests! If you'd like to contribute to Txt's development specifically, please take a look at the issues list for issues tagged with "Help Wanted".
Txt is licensed undder the GPLv3.
Txt uses events to create simple patterns for interacting between Electron's
render processes. Once I've cleaned up the beta, I'll write a little more about how this works and what the benefits are.
I'll write more on this later, but basically Txt is designed to allow you to store data in untrusted locations, such as a cloud service or on a USB stick.
The app assumes your currently running host system isn't compromised. In the beta, your passphrase is managed by your OS's keychain. The beta won't stop you from creating a terrible passphrase and using that. This will change and as I develop this further I will likely add alternate forms of authentication, eg physical keys or webauth or something else. For now, the goal is that, provided you take some basic steps to protect yourself (eg, taking care of your metadata and choosing a strong passphrase), it should be possible to store your work on untrusted infrastructure as long as a readable "Last Accessed" property is not something you need protected.
Finally, Txt does not protect anything that isn't stored by your filesystem. Your metadata - including the filenames of your work – is available to anyone who has access to the disk.
Connectivity and Consent
Much like the app's stances on encryption and data portability, Txt will also treat all connection requests, like HTTPS, as a privilege. Txt uses a small auto-updater, served from Txt's website and for beta this is enabled by default. Before 1.0, Txt will allow its operator to completely block all connections. In this case, Txt's interface will explicitly ask for consent from its operator to connect to the internet to look for updates.
Txt contains no analytics and no logging. Outside of planned export and collaboration functionality, denying all connectivity should result in minimal feature degradation.
There are a number of projects in the works that seek to demonstrate collaborative document editing in a decentralised ecosystem. This is a major feature under consideration for Txt.
In a typical ecosystem, the legal or operational risk is centralised and the responsibility of an organisation through security and governance practices. In almost all p2p collaboration cases, these projects shift this risk onto their users by failing to devise solutions for individual privacy when participating as a node. The assumption that user privacy is an optional extra (and the related dismissal of criticism as paranoia) results in two outcomes: unsafe protocols being used in unintended situations (eg as political tools), or apps and protocols running afoul of legislation simply through their design (eg the GDPR).
In much the same way as Txt respects connectivity as a privilege, communication and identification should be an empowering component to an author's interaction and self identity within a network. Txt will not ship with decentralised collaboration, but work will continue on this problem.
Planned for beta
Planned for v1.0
Once there's something you can actually use, I'll add donation links here!
Grateful for the following people for their help so far:
- Ignatius Gilfedder (Design support)
- Rose Regina Lawrence (Threat modelling)
- Dean Francis (Translations)
Txt is an experiment by the New Design Congress, a research group developing a nuanced understanding of technology's role as a social, political and environmental accelerant. We are a fiscally sponsored project of Simply Secure, a US 501(c)3 nonprofit.