Randomness from the past
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.
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.