[tl;dr] You can access various infrastructure at http://dynamic.land/ including a searchable email archive with stable links. Everything has a documented API so you can build on top of it. To access outside the lab you'll need a login which I sent in a previous email to dynamic-private.
It's inspired by tools and prototypes we've built in the past to augment our group memory:
- The research gallery
- Ways of physicalizing code or software: Bret's code tiles, Glen's code blocks, Bret's thoughts on tangible software
- Our work with binders of digital media: Dave's suggestions based on editor workflows and Rob's subsequent implementations, Bret's email binders, Glen's phumblr
- My attempts to make an image search for the dynamic list (now a reality)
- Glen's reification of moments in a space
- Paula's actuator zoo with links to datasheets
- And especially all of these ideas coming together in the Memex Jam
It's also inspired by tools that augment the room's "muscle memory". There are some tedious tasks that we have to perform again and again. Export the laser cutting file as a PDF, email it to the laser cutter, bring it up on the windows computer. Install all the requirements to get a piece of hardware working on a new computer. Etc.
These repetitive tasks add friction to valuable activities, and it would be better if they were in the "muscle memory" of the computation environment that surrounds us. Some relevant work:
- Bret's quicker cutter to send files to the laser cutter over a web API
- My building on this with Apparatus laser cutting
- Some tools we've been wanting to build around automatic "silhouette printing/cutting" (like for our scale models)
- Josh's whiteboard stitching scripts
- Our notes on IMP design
So based on my previous outline of a "microservices architecture", Josh and I built this out as dynamic.land.
http://dynamic.land/ The main dynamic.land page serves as a registry of all the services and describes how to add a service. The way it works is you spin up a web server either on your development machine or any other machine. Your script registers its address:port with dynamic.land which sets up a subdomain that proxies to your web server.
http://email.dynamic.land/ hosts all of our email by downloading with Nylas. Attachments are stored using the media service.
http://media.dynamic.land/ stores files by their hash (a content addressable store). All email attachments and files put in the stash are stored and indexed here. Each file also shows back links to emails it's used in, where it might be in the stash, what whiteboards use them (future work), etc. This is where you'll want to look to do experiments with image recognition. For example to do SIFT feature detection on this whole corpus and then try to recognize printed images in the space and back link them to emails that use them, etc.
http://stash.dynamic.land/ lets you browse the lab's shared folder (which we're calling the stash). To put something in it just connect (as guest) to dynamic.land's shared public folder in the finder. This is ad-hoc storage, organize it however you want. We set this up when we were compiling our miscellaneous photos/videos on archive day.
http://barcode.dynamic.land/ lets you generate 8-digit barcode images (using the EAN8 format). The idea is to associate a barcode to a URL, then this barcode serves as a link. The barcode service keeps a database of all the barcode-URL associations.
http://printer.dynamic.land/ lets you print to any of the printers in our space (though haven't set it up for the plotter yet). The nice thing is you can send it HTML using CSS inches and they will print exactly.
http://sticker.dynamic.land/ lets you make 4"x3.333" stickers (like the research gallery stickers) for any URL. It tries to find a caption and representative image from the URL you give it, but you can change both of these.
In the course of making these, Josh and I came up with some design principles that seem to work well. First, the front page of each service should describe what the service does, provide a basic UI to use the service, and document the API for building on top of the service. We've been putting our source code on the CDG Internal gitlab. The "canonical URLs" for things (e.g. for an email) should be the thing that the human wants to read (as opposed to e.g. JSON). To provide machine readable access, it's usually only necessary to provide a full dump of the data and let the consumer build on top of that.
After the presentation we discussed and brainstormed additions to dynamic.land.
One big task that will make the stickers much more effective is a real barcode reading infrastructure. Right now we have one bluetooth barcode reader that you pair to a single computer. The reader acts as a keyboard which is monitored using this keylogger which brings up the appropriate page when you scan a barcode.
My ideal would be a dozen readers sitting around the space (like laser pointers). Every screen in the space has a barcode on it. You scan the screen to pair a reader to the screen. Then you can scan any code to bring it up on that screen.
We discussed possible implementations of this with a barcode reading component that uses sound to beep what it reads and then microphones throughout the space. (This could also be done ultrasonically if we didn't like the beeps. Or we could use wifi if we wanted to be conventional and make things overly stacked.)
A mundane task that should be done is setting up regular backups for the dynamic.land computer, in case it gets stolen or something.
We discussed more services that would be fun to have. See above image.