All posts in OpenID

With spring in the air, sap rising in the trees, sun warming the ground as it thaws our hope, it's only natural that our thoughts turn to code.

The Summer of Code, more precisely. Isn't that what you're thinking about?

We're submitting two proposals this year; the first is a collaborative effort with the Open Source Labs to leverage some of the functionality from Google's exposed APIs (and yes, I know, I know, I know). I'll be writing more on the precise spec over the next few days, so check back.

Our second proposal is up over on drupal.org.

For those who don't feel like reading about it elsewhere, here is the proposal:

1. Overview

This application allows users to make friends with any user on any site. This project is proposed in Drupal, but it can be built as an add-on module in any application. This has the potential to allow people to escape from the silos within most networks. Using this module, a person can connect with any user, on any site.

More importantly, this is completely decentralized, so a user does not need to hand over their personal information, or their friend's information, to a service/company they don't know or trust. At the end of this spec, we'll look at possible ways that this application can be extended.

2. Goals

Create a lightweight, extensible, scalable, decentralized framework for connecting people belonging to any site on the internet.

More importantly, make it easy to set up, and easier to use.

3. Implementation

The core functionality revolves around the following tables and fields:

The friend_user table: For a user creating their profile:

• UID -- a user id -- in Drupal, this will be the site members UID
• ProfileURL -- the user's home page, or the page where they want to be recognized. Within Drupal, this could default to a user's profile page, but it could also be configurable via admin settings to baseurl + somepath + username -- this would allow for integration with, among other things, modules like MySite. The user can also manually enter a URL, so if they want their home page to be their own special handcoded page on their own domain, they can make it happen.
• FeedURL -- an RSS feed that presents a view of the user -- this can be their blog feed, or some other feed entirely. As with the profile URL, it can be set to a default value, an admin-specified value, or manually by the user.
• PhotoURL -- an avatar that is uploaded by the user
• name -- Just one name -- for some rationale behind this, start reading here -- FirstName LastName isn't as universal as one might think :)
• email -- not shared publicly, but only between friends -- can also be used in some automated communication

The friend table -- stores records of friends, and of friendship requests

• FID -- a randomly assigned ID for the friend
• UID -- a user id (from the friend_user table -- aka, Friend Of
• ProfileURL -- the address of the friend's profile page
• FeedURL -- the address of the friend's RSS feed
• PhotoURL -- the URL to the friend's avatar
• name
• email
• status -- a flag on whether the friendship offer has been accepted or rejected
• type -- group/categorize acquaintances -- Friend, Contact, Acquaintance, CyberAmigo, etc

The friend_category table -- this table stores user-defined categories of friends.

• UID
• friendcat -- the values in this field appear as options in the UI for friends, and are stored in the type field in the friend table

The friend_request table -- this table is used to keep track of requests for friends

• requestURL -- the URL where the request for friendship was made
• date -- the date the request was made

4. Making Friends

This section describes the core functionality. There are a few ways to get this done, but I'd favor something simple, and leave the exact approach up to the student.

a. Offer Your Friendship

• Navigate to a site.
• Click the Make a Friend button.
• Leave your contact info -- what is the best mechanism for leaving contact info on the potential friend's site, and creating an entry in the potential friend's friend table?

This action should leave a record in the friend_request table

b. Accept/Reject a Friendship Offer

• When a user logs into their "home" site, they will see if they have any pending friendship requests. These requests are stored in the friend table. Users can flag requests as accepted or rejected, and organize the friends into groups
• Accepting/rejecting an offer should prompt an email to the new friend, with an area for a personalized message from the user

c. Reciprocity

While it would be nice to have friendship automatically reciprocated, I don't see it as necessary for the first pass. Thoughts?

5. Additional Functionality

These items would be part of the first version

• Friends Block -- configurable to show x number of friends' avatars -- clicking on the avatar brings a user to the friend's home page.
• Friends Page -- display all friends, with links to their feeds
• Friends' Feeds -- display all feeds, sortable by date or friend. If the feeds are imported as nodes, and displayed via a view, then the feeds would be searchable, which would be quite cool -- but that's a small detail at this point

6. Expanding the Functionality

The functionality described here goes beyond the scope of what would be realistic within a SoC project.

• OpenID integration -- with OpenID, it would be possible to create an overview of daily activity -- I need to look into whether this could be extended to include comments left while logged in using an OpenID
• Profile expansion -- include user generated information such as Likes, Dislikes, Profession, Interests, Favorite Ice Cream, etc
• OpenSearch integration -- create a feed from the info in the friend_user table that could be searched/aggregated via OpenSearch -- this could potentially be another way of finding like-minded people, and would have some interesting applications within large organizations and schools.
• Building the profile wall -- there are a few ways to do this within Drupal, and using one method wouldn't need to preclude someone else from using another. A shortlist of possibilities includes MySite, custom themes of the existing user profiles generated by the core profile module, profiles as nodes, or my personal favorite, a node type that pulls some info from a user's profile and augments that with friend's info collected by the Friends Everywhere module. This last method would allow for comments on the node, and a quick doorway into a user's online identity. Combine this type of functionality with field-level access control and there are some pretty broad possibilities for only showing specific content to specific users.