Randomness from the past

A little over 3 years ago, I was learning node and wanted to try to make a project with it. Since I had no idea what I was doing with node and all of my experience with JavaScript was on the client side, I ended up making this project called The Great Brain. It didn’t make use of any of node’s capabilities. It was just a basic Express web server that housed some client side JavaScript which contained a list of servers that were returning text or an image and an optional audio clip. Each server would be randomly pinged to return content to play back on this app in an endless loop.

Keeping services small, keeping contributions simple

One of the main reasons I made this project was to encourage friends to contribute to open source code without being overwhelmed or scared. And it didn’t force anyone to leave their programming language of familiarity, whether it be PHP, Ruby, Python or Node. Having someone contribute a small service and pull request to a config file makes all the difference in their confidence and motivation.

Second, creating small services that follow the same API rules forces constraints that allow developers to think of creative ways to integrate content. When you don’t have choice paralysis on all the different things you can do with the service, you are left with doing interesting things with your single source of output.

Three and a half years later …

I know a little bit more about node now, so I can revisit this project from a different angle. After watching people create interesting bots, bookmarklets and hacks for Meatspace Chat, it made me think of other projects that could encourage this ecosystem of “fun/weird hacking”.

Revisit.link is a similar idea to the Great Brain but moves the concept from immutable to mutable data. Instead of returning a static image or text or audio from a random server to a central hub for presentation, we are passing media through all the services and having each change be affected by the previous change.

Imagine taking an image and uploading it on the central hub - in this case, it would be hub.revisit.link and passing it through 4 external services - one that creates glitch affects on the image, one that distorts and one that turns it into an animated GIF. But imagine for the fourth change, you run it through one of the previous services again. So you have a flow like this:

original image -> glitch -> contrast -> animated -> glitch

What happens in the service is that the data URI for the image is passed around through a consistent API from all services. Similar to the Great Brain what language you use to create the service is irrelevant - as long as the same JSON data is expected and returned.

The Revisitors

To keep the project focused, I moved all revisit.link projects into a Github organization and various collaborators are starting to think of small projects that they can add to the list of available services on the central hub.

This is in a very early stage of development and we’ll likely be making small changes to how the API is handled and what kind of additional data we want to support. For now you can access the current spec on revisit.link.