For whoever is reading this: you should buy the "A people's history of computing in the United States" by Joy Lisi Raskin -> .

I will be updating this channel to reflect who truly was a computing pioneer versus who the commercial narrative branded as.

summary for week 5

Lots of Raspberry troubleshooting this week. I have been keeping track of my code so far here: (it includes the dat part too). I am preparing for a demo with one fully functional (hopefully) object this Wednesday. I have decided to go with resin casting and a simple button or "push" interaction (design n.3 from the examples showcased above), but will be working on n.4 until I figure out the Raspberry and the charging details.

The interaction I have been working to get is the following:
- the Raspberry plays audio files continously
- a button press starts the recording, lighting an LED as well
- a second button press stops the recording, the LED is off
- the Raspberry automatically resumes to playing audio.

The issues I was having were with figuring out the right Python library to work with, getting the timing of the button presses right, dealing with bad recorded audio quality...still have to work through them but I made a lot of progress.

For Wednesday's demo, I plan to sand the acrylic and surround the LED light with a piece of dichroic film, to see what sort of "diffused light" effect I can get.

After Wednesday, I will start casting experiments. In terms of final result here is a mood board of what I am going for:


Been around for a while (since 2013 in Chrome)
Way to directly connect browsers (clients) to each other
SIP—earlier model of doing this—shoved into HTTP and JSON
Inside of WebRTC it's all these weird formats from the 90s
Asymmetric communication: Simple case
Browser 1 will make an offer
Browser 2 gets the offer and writes an answer, sends that back
They use the information in the offer and answer to connect
Candidate IP addresses
IP addresses browser thinks it will be reachable at, gotten by checking interfaces, will include local addresses (candidates)
try each and find ones that work (are reachable)
Signaling server
How are the offer and answer transmitted?
Use a shared server that both can reach to transmit offer and answers
Usually done with websockets but not required
Only used in establishing the direct connection
Unreachable network case (NATs)
If both are on separate private networks, no candidates are reachable
Use NAT reversal technique called STUN (part of ICE protocols)
STUN server (separate from signaling server)
Browser reaches to endpoint and asks for its (publically routable) IP address and figure out how it's NATted (what port is it "actually" on)
A bunch of public ones exist run by large scale third parties (Google, for instance, or anyone running VOIP)
Uses that as part of its candidates
No need for both clients to use the same STUN server (or even for both to use a STUN server, if one side is routable)
TURN servers
Some NAT configurations might not allow an alternative machine to ingress on the the NATted port number (i.e. the source must match the destination the connection was initiated to)
You can ask for a relay to resolve this (TURN server)
It will return a port number an an address that works as a proxy to connect to you
Google stats: ~8% of connections are strictly NATted and require TURN
Geographically distributed to reduce latency
Multi-peer connections?
Up to 4 or 5 connections, often just do many-to-many connections (each client connected to each client)
This stops scaling fast (factorial number of total connections!)
SFUSTU server acts as a mixer and can take uploads and stream them back now
Adds a bit of latency but is usually good enough
“Selective Forwarding Unit”
Could a client act as the "server"?
Seems reasonable, may be a connectivity issue
Daisy chain model, where each peer passes it along to the next?
Clearly a more latency driven-model
Can we determine available bandwidth?
WebRTC tooling might not enable it but Skype once worked this way
Got Skype kicked off CERN networks
If it decides to make you a supernode, RIP internet connection, no choice
Hence Skype is no longer working this way

What is this about?

This is a way to document the progress of my Master's thesis. It's partly a way to force myself to do work every day, partly a way to participate in, and partly a way to use tools developed by the community, like the platform this website is built upon (

I will be posting images, thoughts, short texts, sometimes incomprehensible or cryptic bullet points, but hopefully in the end I will have a working prototype of my thesis proposal.

Roughly, the idea is that I will design, fabricate and deploy in the world a number of objects that will capture, play and share in a p2p way audio messages. My motivation is to explore how a small decentralized network, supported by these physical nodes, performs in a real world scenario (in this case, the MIT campus), how the audience interacts with it and whether the nature of information collected by these objects differs from what could be carried by a conventional website. I am curious about the interaction design component, whether users would care about the fact that this is a non-centralized repository of information, and whether they are ready to sacrifice some of their "user comfort" in order to prioritize locality and data ownership. This is an experiment aiming to probe the question of whether, and how, we can bring the Internet back to a smaller scale in a meaningful way. Hence the title, which is "Internet as an object". The PDF with the submitted abstract is below.