the goal with 友 (tomo) is to create a completely decentralized libre hardware and software platform that is focused on privacy, ease of use, and hackability. these devices should be as simple as possible. somebody with basic electronics skills should be able to assemble anything in our product line without any trouble.
友 is a simple line of DIY-core devices. hardware you can trust because you assembled it yourself. we put all of the control in your capable hands. the plans and specs are all available on source. these are currently a work in progress, but the goal is to make something that you can assemble in your garage with a 3d printer and some knowledge of electronics. we picked rpi for the mainboard because of the ecosystem of cheap, easily sourced parts.
we want to provide a starting point for hackable, modular, mobile devices. the first iteration is based on stuff that is already on the market. (very) long term, we would like to look into custom SoC based on free ip cores so we can ship a fully libre hard/software stack.
to start with, we expect some enthusiasts to pick up our devices for experimentation and customization. we also want to use tomo as a vehicle for our p2p application platform; there is still a lot of development to do there, but we want to tightly integrate with our hardware to get everything working flawlessly. the idea is to create a sort of "freedom garden" of libre apps, services, and hardware.
we want to be the best/most friendly hardware and software platform on the planet
the computer should be invisible; our focus should be on the tools that do things with (or to) computers; interfaces are everything!
the reason why tomo and heropunch as a whole are so focused on making p2p tech easy to develop for is exactly this. by freeing ourselves from the global internet and making device-to-device interactions the norm, we open up a new realm of possibilities. like, i can't imagine every cool thing that people will create, but i do think that the shape of the systems we work with influence the kinds of things that we build.
IoT has problems still, but they are more tractable when i can isolate my "smart things" from the internet. for one, my shit won't break when my internet is being flaky. whenever i move, i don't have to worry about having internet installed before i can have a movie night with my friends. or a dance party or whatever.
apart from interfaces i think the next biggest area where technology draws attention to itself is when it breaks. specifically, when the software design is based on assumptions that don't hold in the real world (always connected internet).
tomo provides all of the tools and facilities you need to create and distribute mobile-friendly, self-hosting, peer-to-peer applications. the recon runtime is designed to provide a familiar api for web developers. we want to make it easy to transfer your knowledge from working with browsers to building the future.
tomo isn't intended to dictate how the future will look. the goal is to create a collection of interoperable tools and libraries that will allow us to more easily exchange ideas. the first thing we need to make this happen is a lingua franca for distributed application software. Elixir makes it easy to write massively parallel software with a high level of reliability. the familiar ruby-like syntax is easy to read.
mobile performance is critical to our success.
low-level software is written in C, to exacting standards.
why control the whole stack?
since we are creating this platform from scratch, why not do it right all the way down? tomo is a fork of alpine linux. we also maintain a fork of the postmarketos aports tree that gives us access to a growing collection of mobile devices.
alpine linux is a small, security-focused distro. due to the highly-connected nature of peer-to-peer applications, it is important to minimize the attack surface of the system. alpine gives us a suitable starting point for building the network os of the future.
RFC drafts are welcome and should be tagged
RFC-Draft. comments are welcome,
but please keep in mind that a draft is not a complete document. the
RFC-Proposal tag indicates that the document is ready for ratification.
approved RFCs are tagged
RFC-Approved. upon approval the RFC should be checked
into source control under