tomo is a hardware project with the goal to create secure, auditable personal computing devices that can be assembled from parts by users with adequate knowledge of electronics. the first milestone here is to create a smartphone that i have named #cybredeck. the enclosure is inspired by the ubuntu edge and includes all of the hardware features you would expect from a modern smartphone (most things, including cell are optional).
one, rather important, hardware feature that i would like to focus on is the TPM that i am including in cybredeck. this device enables us to tie some very important crypto operations to the hardware. now, i’m not quite a security expert, so i might need some help getting this exactly right in software, but i think this is an important harware feature that can be used to make your device much more secure and resilient against scary hypothetical situations.
peer-to-peer applications are too much work. there isn’t any sort of coherent structure or even a lot of tools to help you create something like this. relax isn’t so much an answer to this problem, rather it is a way to start exploring what a completely peer-to-peer application platform might look like. i am staring with some very basic building blocks and working up to what can hopefully become a very productive toolkit for building properly serverless applications.
in order to facilitate exploration and experimentation, relax is implemented in a subset of clojure that can be compiled to ISO C++11 using ferret. clojure is a functional lisp dialect designed for concurrent programming. mobile devices often have access to many slow cores and heavily throttle fast cores to reduce battery drain. because of this architecture the and the energy constraints of mobile devices in general, building programs that make effective use of concurrency is critical for acheiving good performance.
the first concept that relax builds on is the idea of a personal compute mesh, inspired by plan 9. grid enabled you to schedule jobs on any device that you have paired to your user account. in most cases, these jobs will be interactive process that run on the device you are holding, but for many applications running jobs in the background (possibly on another, more poweful device) might be expected behavior.
i am aware that anonymous systems can easily be abused, but abuse isn’t a a problem that i am trying to solve with
relax/router. my goal here is to create a flexible tool that can be used to enable a wide variety of interaction models and ensure that users have access to the highest level of privacy that i can afford them.
peer-to-peer applications have a lot of really important upsides that map very well to the way people communicate and share content on the modern web. however, peer-to-peer in general has a serious privacy problem, in short: you don’t have any.
implementation that works with grid to provide anonymous network access from any internet-enabled locale.
this anonymous overlay network not only simplifies NAT-traversal (which is, unfortunately, still something that has to be dealt with), but also enables us to decouple your identity from your network address. the implications of anonymos pseudonymity are kind of interesting, i think. by starting with anonymity, you always have the ability to forgo any kind of persistent identity. however, using public keys as some basic trust systems it is also possible to have strong persistent identities, or anything in between.
vfs is now bfs, and is build on top of ipfs, borrowing some ideas from tahoe-lafs.
abstracting storage from a spefific host is challenging to say the least. vfs tackles a somewhat more tractable subset of this problem: storing static files in tahoe-lafs. vfs automates large portions of the setup required to run a tahoe-lafs storage grid and includes a number of utilities/plugins that give you access to a fairly generous amout of cloud storage at no cost!
vfs ships with two additional client apis that make it easy to retrofit legacy applications into your distributed storage system. first, FUSE allows you to work with your files using standard file system commands: anything from mpd to shotwell. second, an s3-like frontend integrates perfectly with a lot of self-host-able web applications and storage/backup utilities.
i’m actually going with secure scuttlebutt for
relax/bfswill have ways to access torrents. i’d like to be able to transparently leech/seed from the internet archive webseeds and other places like library genesis.
more on this in the next post
the last piece of the puzzle is peer/service discovery and messaging. i think bittorrent is a perfect fit for this task: mutable dht entries for authenticated pub/sub, publishing service descriptors in small torrents, and standard file transfers. most of these are possible using any torrent implementation, but even the more interesting features (mutable dht) are standard, even if they are not readily exposed by common clients.
is a bittorrent daemon with a few special capabilities that runs on the mainline dht. pub, sub, discover. supports uTP and webtorrent transfer protocols. mutable dht entries. lan discovery. a lot of this stuff is similar to ipfs
, but superior in a lot of ways as well. i have some strong opinions against ipfs that i wont go into here.
this criticism is somewhat misdirected. ipfs is a fine piece of technology which enables some very interesting use cases. i do object to the decision to fork the mainline dht and their insistence on separating themselves from the bit torrent network and the idea that “intellectual property” is an antiquated model for managing information. i understand the motivations from a business perspective; protocol labs may not wish to make a stand on this issue, but they really should.
these are the areas that i am actively exploring. everything is new and in various stages of implementation. i will be using this post to keep myself focused and to provide some context and reference for others as to what i am working on. i expect some sections will be amended, added, and extended over time.