This is a copy of a proposal on the OpenAcademic wiki -- feel free to edit it there -- for those with an OpenID, it's OpenID enabled.
It's on d.o at http://drupal.org/node/127554
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
- 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.
Comments
hm, but would it be possible
hm, but would it be possible to request a friendship with anyone of another site? How is the information transmitted? Have you thought building upon an existing standard? Do you know FOAF? (http://en.wikipedia.org/wiki/FOAF_%28software%29, http://drupal.org/project/foaf)
absolutely -- that's the point of it
RE: "would it be possible to request a friendship with anyone of another site" -- that is exactly the goal of this module/app -- to allow users on different sites to connect across sites -- so, for example, if this app was also built out as a Wordpress add-on, anyone with a Wordpress blog could connect to anyone on a Drupal site (providing both sites had this functionality in place) -- really, this is intended to be something that is lightweight, and provides an easily accessible solution for people who want to create a network of friends without handing over their personal info to a service -- although, if this functionality was installed on a Drupal site, it would effectively be a service.
The information could be transmitted via xml-rpc calls, or as an xml file -- As I say in section 4a of the proposal, there are a few ways of getting this done, and this is an area where I would rely on the expertise of those who know more than I do -- the advantage of something like an xml-rpc call is that, once it's configured, it's easy -- the disadvantage is that many people would have a hard time setting that up themselves. But like I said, there are people who know a lot more about this than me, and I'd gladly follow their lead on this. But your observation is correct: the method of exchanging information is the most complex part of this app.
RE FOAF: Yes, I know FOAF, and FOAF (and specifically, the lack of uptake of FOAF) is one of the things that influenced my thinking on this -- this idea is intended to be simple, and lightweight -- a person's "identity" is their preferred homepage (their static self), an rss feed (the content they create/find relevant), a name, a picture, and an email -- once this basic functionality is in place, it can be easily expanded to support more robust technologies (like the OpenID 2.0 spec, which is a whole lot better with attribute exchange), friend-specific content, searchable friend content, etc -- but really, this is just intended to be something simple that allows people to break down the silos that currently exist on most sites -- more of a starting point than a finishing point.
FunnyMonkey
follow up
Is somebody working on this project in the end?
--
Check out more of my writing on our blog and my Twitter account.
At this writing, the review process is still open
So it's status as an SoC project is still open
However, the really open question is whether to implement this outside OpenID 2.0, and then extend this functionality by integrating it with OpenID, or to just implement it on top of an OpenID 2.0 server within Drupal -- the ability to share personal info/attributes would effectively be solved by OpenID --
When I first wrote this up, I was leaning toward something that could be implemented without OpenID -- but, given how much easier this would be to implement on top of OpenID 2.0, I'm leaning toward solving this using all that the OpenID 2.0 spec brings.
So, the short answer is yes, we'll build this if no one else does, and regardless of whether it's a SoC project or not. If this could be paid client work, hey, so much the better.
FunnyMonkey
So now that its not a SoC
So now that its not a SoC project, what will happen with this?
MinGGl
we are working on some similar stuff but more involving open standards so a bottom up approach
from your top down approach you should check out http://www.minggl.com/
erm
I think I'm missing something here --
re
The solution I outline above would be completely open,the code that runs it would be freely available, and the overall solution would be completely completely bottom-up, as users (not a service) would have complete control over their user data and their friend data -- both control in the sense of being able to edit it, but also control in the sense of being able to move it around from site to site --
From your post on http://leagueoftechvoters.org/drupal/?q=node/135, you seem to be looking for something like the OpenID 2.0 spec (and honestly, just about all of what I describe in the remote friends post could probably be implemented on top of OpenID 2.0)
Cheers,
Bill
FunnyMonkey
Start with OpenID 1.1 and FOAF
I'd love to see something like this become a reality.
I'd suggest implementing it on top of well-established formats/protocols such as OpenID 1.1, FOAF and XFN (this way, you get numerous readily available networks, e.g. LiveJournal).
I might be able to contribute a protocol specification and, optionally, a phpBB implementation.
Drupal + phpBB + OpenID
--
Drupal + phpBB + OpenID