Designing the Feedhaven Ecosystem

Feedhaven Diagram 1.0

We’ve been working a lot recently to figure out what the Feedhaven system should look like.  Right now it’s relatively simple, but to properly work in an ecosystem of applications it would need some additional complexities.

Feedhaven Instances
In this case a Feedhaven Instance / Server is shown to the right.  A user can set up their own Feedhaven instance, or can use a company’s hosted instance (like Feedhaven.com).  This instance is in charge of providing a GUI for the information, storing data on users, handling API keys, and handing the standard Feedhaven data.  This should be able to work on many NoSQL databases, though we plan to begin with MongoDB.

Authentication
Mozilla Persona seems like a good fit for authentication, especially because it can be standardized among all Feedhaven instances and applications.  Hypothetically Persona could provide proof that an application has confirmation from a user (to send to other applications), but I’m not sure how this would work.  It’s also open source, distributed, easy to set up, and quite minimal.  With Persona integration in the browser, log-in may eventually be a relatively easy thing.

Data Validation
Hypothetically all items and feed data would be validated with external JSON schemas with version numbers.  I imagine that for large amounts of data the schemas would have to be cached, and it may be that validation isn’t required, but is possible with an extra function.

Simple Translation Apps/ Simple Feedhaven Apps
The idea for this is that users can create API keys with specific permissions at their Feedhaven Instance.  Then this can be given to an external application to allow them to access Feedhaven data without registering with Feedhaven.  Applications that do this would have restricted API call allowances, but this should be fine for many apps.  This is how many major APIs already work; with API tokens for some apps that don’t have to register. These simple apps could do things like read emails from Gmail, convert them to a common email format, and send these to a specific Feedhaven Feed.  They could write or delete specific feeds, and read new common emails from these feeds and then send them off to Gmail.  Whether the app does polling or subscribing to access this content from Feedhaven would be up to the application.  In addition, these apps can be used to just view Feedhaven data.

Translation Manager Apps
There are hundreds of thousands of applications to talk to, and much of the code to translate each and send/receive to Feedhaven will be the same/similar.  I would imagine/hope that platforms could exist that could accept hundreds or thousands of snippets for conversion with different apps and schemas, and run them as needed. For this, rather than using a standard API token, these apps would have to register directly to each Feedhaven instance.  This should be standardized and done via API calls, when needed.

Future Development
Of course, the system still needs to be built. The idea is that ecosystem would be fully modular so each part could be built independently based on well defined interfaces.  However, this will take a lot of trial and error as the interfaces are changed based on the workings of the components.  Updates will come at this blog.

Comments