Buccanner Update Dec 2013

For all of the techies out there, looking to win this prize we have a software update for you.  Read on..

The printer

Overview

The Buccaneer is a stand-alone machine. This means it tries to handle on its own as much of the printing process as possible. We try to make it smart and make sure it lets you know when assistance is needed.

The software on the printer is split among many different Linux processes. We try to keep as little dependencies between those processes as possible.

To name a few, the printer boats a message queue server, an open-source slicer, a driver to interface with the mechanics and sensors, a separate small driver for the front light, a software updater, and “the propeller” −the smart process.

The message queue server is used to make the printer contactable by users from anywhere −Internet, local network−, bypassing NATs and firewalls. The propeller subscribes to the message queue server to listen for requests from the users, and uses it to send status infos as well. It maintains the printer’s task queue.

Tasks include obviously prints, but also actions like loading the material in or withdrawing it out −to change color for example. It sequentially downloads and slices all objects waiting on the queue so that they are ready to be printed when their turn comes.

How to hack it

If you don’t like our software, no hard feeling, you can hack your own software into the printer.

We will provide more detailled instructions when the time comes, but in short : * Power off the printer, open it, and take the SD card out. * Go to /home/buccaneer/bin/, and deactive the parts you don’t want. As long as you only modify what is inside the folder /home/buccaneer/, you can always recover the original system by : * Putting back the SD card in place and powering on the printer, * Pressing the reset button.

This will reset the original content of /home/buccaneer/ only. Any change outside the folder will remain − at your own risk. In the event you dammage files outside /home/buccaneer/, we will try to provide for download an image of the full SD card.

The printer UI

You may have noticed, the Buccaneer has very limited connectivity with the world − no buttons, no screen, no usb cable.

All of those featured are delegated to you favorite device − smartphone or PC. The printer provides a straight-forward API that is reachable through your local network or the Internet. The printer UI −running on your device− connects to this API to give you full control over the printer.

As of now, the UI has been written for browsers in Javascript/WebGL/WebSocket. We are working at porting it into native iOS, Android and others. Expect an initial setup process fairly similar to Google Chromecast − Youtube is full of demo videos if you have never tried yourself.

Hackers, you should find it trivial to connect yourself to the API and customize your own interface.

Message queue reliability, security and privacy

The current implementation of the message queue is fairly conservative. The printer combines Apple Bonjour and UDP broadcasting to be found on the local network by the UI. If the UI fails to find the printer, it will resolve to connect to a centralized relaying server of ours −on the Internet.

In this later scenario, messages are sent from UI to server to printer −and back from printer to server to UI− through TCP connections established by the UI and printer to the server. We have looked at implementing NAT hole-punching as potential optimization. Messages are encrypted end to end, therefore the only thing we get to know from the relaying server is which UI connects to which printer, and whether you are printing or not −judging from the frequency and size of messages.

If the relaying server fails for some reason −overload, DDoS or other−, your only way to communicate with the printer is then through your local network. A simple way of improving reliability and privacy is to provide the code of the relaying server for volunteers to run forks −thereby distributing the relaying.

A more robust solution considered is to relay messages through a decentralized rendezvous network like I2P or similar. Using tunnels of length 1 provides fast, private and reliable relaying. Extending the tunnel length to 3 −optionial− sacrifices responsiveness for high levels of anonymity − for whoever values it.