| Verson: | 0.1 |
| Updated: | May 28, 2008 |
The Ciabe Portable Friend List provides partner sites with a complete social network that they can “plug in” rather than rebuilding for themselves. This portable network spans sites, and enables people to bring their friends with them as they move around the internet.
It features:
All of these features are available as either fully built UI or through API calls.
A partner site provides each person with a login to that site (the “Partner Site ID”). The user then “links” that site ID to an account with Ciabe. Ciabe generates a Ciabe Local ID (see “LID”, below) for this user on this site, and returns it to the site. The site then uses that LID any time it communicates about this user with Ciabe.
Design goals:
The front-end, application logic, and API interfaces are implemented using Ruby On Rails. API interfaces were designed using a “RESTful” approach, and great care was taken to follow best practices (use the full HTTP command set, return standard HTTP status messages, etc)
The existing prototype is implemented as a set of Ruby on Rails applications, backed by MySQL databases. This approach offered development speed and flexibility as we built early revisions of the product, and will provide sufficient performance to power it through the initial growth phase. As service usage reaches scale, we believe that a different approach will be required. The operations that underlie Ciabe services can be efficiently implemented using “loose coupling” techniques such as the Map / Reduce approach pioneered by Google for queue-based job management. Several Map / Reduce tools exist, and we are currently evaluating the performance of the open source Apache Hadoop.
The API and partner libraries were designed to provide a clean separation from the back end, so we believe that it will be possible to switch from the Rails prototype to its replacement. Our goal is make the switch without requiring our partners to make any changes to their deployment.
Engineering was done in Kiev, Ukraine by a team of experienced Ruby and Java developers. The code was developed with automated unit and integration test tools.
The entire API set is implemented as a set of REST methods. Each partner is assigned an API key, which must be used to sign every request.
To simplify integration, we provide interface wrapper libraries for the most common platforms. Ciabe currently provides Ruby gems and Javascript libraries. Support libraries for .Net, Java, and PHP are also planned.
The current version of Ciabe was implemented using a MySQL database, however we are currently evaluating the Apache Hadoop system as a way to support larger scale. We believe that the access patterns will be efficient to implement as Map/Reduce methods.
All Ciabe UI modules are implemented using the same APIs that we offer partners. We use no private APIs except those that manage partner keys and priviledges. This “eat our own dogfood” approach helps ensure that partner functionality never suffers to support our own products.
People are uniquely identified to Ciabe by either an email address or an OpenID. There is no requirement that the partner site ID and the Ciabe user ID be the same. A user may wish to link their Ciabe portable social network with accounts on several sites, each having a different ID.
They can associate multiple email addresses with their accounts, with one email address is considered primary. The primary email is used any time that Ciabe must communicate with the user. All email addresss must be verified.
Users can associate multiple OpenIDs with an account, and all are considered equivalent. An OpenID is considered equal with the primary email.
Each user is uniquely identified within Ciabe by a Global ID (GID). The GID is an arbitraty identifier, and is the key that Ciabe uses to track this user’s data. The GID is never exposed to partners or the end user, and is only used internally.
For each site where the user registers, Ciabe generates a Local ID (LID) that is shared with the partner site. A person will have only one GID, but will have a different LID for each site on which they are registered. A site can only use LIDs that have been assigned to it, ensuring that no site is able to see data from any other.
Users are “friends” when they have both affirmatively agreed to be linked. In most cases, this is implemented by sites as an invite / accept sequence, but partner sites are free to implement this however they choose. From Ciabe’s point of view, the important step is that both users have agreed to be treated as “friends”.
If the site is using the Ciabe UI, the friend invitation and acceptance will be handled entirely by our system. Ciabe will notify the partner site whenever two users form or break “friend” relationships.
If the site is using the Ciabe API, they notify Ciabe each time that two of their users become friends. A “friend” relationship is valid only for the site on which it was created. Users may be friends on one site, but not on another.
Ciabe notifies sites when two of their registered users have become friends on another site. This enables the site to say, “Your friend X from SomeOtherSite is here as well. Would you like to invite this person to be friends here?”. It the site uses the Ciabe API, this is done automatically.
Here is how Ciabe recommends friends:
Ciabe provides cross site groups and roles. Group members can be from any site. Each group is identified by a GID. Sites can use the API to determine:
Groups serve several purposes in Ciabe:
Groups can be either Public or Private, and either Open or Closed.
Ciabe provides a full “contact” API for sites to use. This is, essentially, an address book. Relationships listed here are not considered “friendships” because they haven’t been affirmed by both parties.
The contact list importer is only available through the full UI.
With the goal of making life easier for partner sites and getting them live quicker, Ciabe makes its feature set available both as a set of APIs, and as full UI products that use those UIs. Sites can save development time and effort by using the pre-built UI, and then migrate to their own custom UI
Ciabe hosts the pre-built UI pages, and the partner simply calls a method to display the appropriate page. Ciabe uses OAuth to authenticate the user. The partner can optionally provide a CSS file to customize the look and feel of the Ciabe UI. User actions are returned to the partner via a callback.
Pre-built UI components are fully skinable using CSS, and can be made to match the existing site UI.
Choosing the full UI does not in any way prevent the site from making API calls. The site could easily start off with the full UI and then move over to custom UI.
Ciabe provides sites with a full-featured Contact Manager page that can be skinned using CSS. This is common functionality, and by providing it pre-made, Ciabe lets sites focus on the areas where they can add the most value.
For sites that wish to build their own UI, all Contact information is also available via the APIs.
Ciabe is dedicated to the idea of Data Portability, and allows users to download their contact information in CSV and hCard format.
Ciabe has included an open source Ruby gem that imports contact information from AOL, Microsoft Hotmail, Google GMail, and Yahoo! Mail.
Ciabe provides a full address book picker for sites that do not want to build their own, or that want a basic product to deploy while they build their own. The purpose of this tool is to display the contents of the user’s address book and allow them to choose contacts.
When the partner site asks Ciabe to display the address book picker, they are provided with a unique ID that will identify this request. When the user selects their contacts and presses “Ok”, Ciabe invokes a callback method on the partner site and returns the request ID with the data.
Ciabe provides a generic user profile for sites that do not wish to build their own.
The profile provides:
All information is controlled by a robust permission system that allows the user to determine which viewers can see which information. The Ciabe Groups platform is used to provide
Sites are not required to use the Ciabe profile, and are free to make their own.