Adding meta data to other services - Introducing


Before I just start speaking and nattering on about how we should concern ourselves with the ability to add our own data to the content we distribute across different services. I think it would help that you, the reader should have a rough idea of what I am trying to achieve.

As a university student, I am currently tasked with making a final year project. This project can be on anything we want. I've proposed a system that allows people to pull in content from different content service providers. Our content is always distributed across lots of various places. This isn't always an issue, in fact it's good from a back-up and data storing perspective.

As a person who sometimes has to use other people's services is that I'm locked into the data and content that these services provide.

As an example Youtube is very cool. It does all the hard work for me and developers like myself can request the videos. Youtube deals with all the infastructure and hardwork, then gives me an api to pull them into my own applications. I once found myself in a situation where I wish I could easily categorise and pull in videos based on site specific categories. This doesn't exist on Youtube.

Why not roll, your own system?

If I had the time maybe I would of. I could of pulled them all into a database and then added the categories myself. I never forgot though.

Humble Beginnings

At first I wanted to make somesort of Youtube CMS. You would give it a channelID and then it would store references to them and then give you the ability to add extra types of data to the videos.

After some review and feedback, it was realised that maybe I was being too boring. My idea was called 'rather pedastrian' and people of reddit thought why make another CMS, why not integrate into an already existing CMS. Of course they were right. So with a glass of wine and a whiteboard I decided to re-think everything. This is how was born.

Threads of content, all inter-weaved with your own data

Braid was made from the thinking that, actually we should consider all the different types of devices we have, so really it would be smart to built it on the basis that all of the web works. The HTTP protocol, or more specifically a HTTP REST API. By doing this, any device now, or in the future can use it. Any website can integrate it. XHR requests can fetch data, IOS SDKs can be made, Node.js Modules can be written all based around this central, and fundamental technology.

We should be able to store threads of content from different services. Youtube, Soundcloud and more. Rally a community behind. Give people the tools and see what the people will make, not just me. Will people combine threads of service and then easily add their own to it.

Who is the audience

This is really a tough one, an api is aimed at developers. This means not-technical people who don't develop applications and websites won't really know how to use it. They might be able to learn, but they may not be interested in learning development.

First and fore-most my audience is developers. I have infastructure to write, documentation to write and APIs to develop. After this, if I can rally a community around this and try and make the service community driven then it could be used to fill the gripes that potentially lots of other developers have too with certain services. Instead of me deciding what service people should be made available next to integrate. it should be up to the community.

It also means a, kind-of, recipe book can be made of common ways certain content services can be combined together to create cool things. To finally bring the entire thing to the non-technical audience a library of widgets can be made that will be made from the very API I am planning to make. This will then allow the everyday developer or a small-site owner with minimal knowledge of how to program for the web to embed functionality into a website or application without the extensive technical know-how.

How to add this extra data

To add these extra layers of data ontop of content that is pulled from different services. I have used the term modifier as a way of plugging new data into an entry from a stream of content. A thread will know what modifiers are attached to it, The system will then know that it should leave some extra fields blank that can be filled in by the user on a type of admin for managing the streams that come into the braids and the modifers they wish to attach to it.

The idea of a modifier is still very much in the works, the thinking right now is that there should be modifier types, such as a collection modifier that allows you to collect and group the entries based on a certain term. This is similiar to how categories or tags work. Another is a content modifier type that allows you to add extra text based content to an entry. There could be much more and hopefully many more in the future too. Supplying modifer types means you could add certain types of functionality that the services provided normally can not. It would be an understatement if I said modififers were not easily the most fundamental part of this entire project, if it can't be built in a flexible and easily maintained way then this project could easily come crashing to it's knees.


I want to make a system where you pull in lots of services dubbed a 'thread'. Add extra data through the use of 'modifiers' and then provide api endpoints for all the threads with the new data from the modifiers attached. This is known as a 'braid'.

This is so that we can plug the functionality we wish some services provided.