Socnet - Social Networking for Geeklog

This is a copy of my project proposal to geeklog for GSoC 2010. It will be updated based on my discussions with the team.

Updates:

April 18: Updated Boilerplate plugin to work with the latest geeklog. Available at http://eight.pairlist.net/pipermail/geeklog-devel/2010-April/004965.html

April 10: Core patch is progressing well. More discussion at http://project.geeklog.net/tracking/view.php?id=1106

About Me:

I am Javed Khan, [tuxcanfly@gmail.com] I am a fourth year student at one of the premier engineering universities in South Asia. I have been passionate about open source development ever since I came to know about it. I was the runner up in a technical competition conducted by IBM on the topic Web 2.0 at our university.

I am interested in all things related to web development, desktop compositing and p2p networking.

I have worked for a in-house Online Notice Board application under the Center for Software Development division of our university based on LAMP and some AJAX, jQuery UX enhancements.

I have developed a Project Management application based on LAMP for a national laboratory during a 3 month program as a part of my curriculum.

I have contributed a patch to allow transfer notifications based on libnotify in linuxdcpp, which is an opensource p2p file sharing client application written in C++.

I discovered geeklog when I was looking for a good CMS to host on our university's intranet and I liked its security features and speed. My knowledge of PHP helped me in digging through the code and exploring its plugin architecture. I have tried to resolve a feature request related to the captcha plugin in the geeklog bug tracker. I have also been discussing socnet on the list for a while.

Abstract:

This project proposes to add social networking support to geeklog. Currently, only admin can create and moderate groups. Socnet will provide this feature to regular users. Plugins can take advantage of the socnet API to allow their content to be shared among the users of socnet groups.

Explanation:

User groups:

Joe Muchiello has provided a core patch to enable group ownership. Socnet will use this patch as a base for managing user groups. Socnet will allow users to create a group and manage the users in the group. There will be two types of groups: public and private. Public groups are accessible to all members. Any member can send a join request to a public group. The group owner will moderate the join requests. Private groups can be viewed only by the group owner. The group owner will send join requests to the users. When a user accepts the request, he will be added to the group. The membership handshake will be managed by creating a random token somewhat similar to reqid token for new password in users page.

The member will manage his groups from the groups tab in socnet settings page. The privacy tab in the page will have a block for socnet related privacy settings. A permissions tab will have default permissions for each content type. The default permissions can be overridden when posting the content using the permissions widget.

As mentioned by Randy, socnet will provide hooks to create/edit/delete items that will be used by the plugins to secure their content through socnet. Some of the methods related to user groups are:

  • SOC_create/edit($type, $args)

  • SOC_delete($id, $type)

  • SOC_sendRequest($from, $to, $type, $template) - used to handle friendship/membership requests

  • SOC_create/checkToken - used for handshake

  • SOC_add/removeUserToGroup($grp_id, $uid)

  • SOC_getMembers($grp_id)

Permissions:

The user will be able to control which groups view the content he has posted through socnet. User can post an object to more than one group.

Socnet will provide a permissions widget which will be a revamp of the permissions widget provided by SEC_getPermissionsHTML. The exact UI control to allow multiple groups to be selected is not yet decided though I am inclined towards using an AJAX based auto complete text box.

Table gl_socperms: Which groups are allowed to view a given object?

object id | object type | group_id

Some methods that socnet will use and provide are:

  • SOC_getUserPermissions($id, $type, $uid)

  • SOC_getPermissionsHTML($id, $type)

  • SOC_getGroupsWidget($grp_id)

  • SOC_savePermissions($id, $type, $grp_ids)

Notifications:

Use case:

    1. User A posts new content, story for example.

    2. User A sets read access to 'friends' group using the permissions widget which means only users in 'friends' group can read this story.

    3. User A also has 'coworkers' and 'family' groups who will not be able to 'see' this story.

    4. User B is in User A's 'friends' group.

    5. User B has allowed notifications from User A.

    6. User B gets a notification containing a link to the story.

So when the user posts a story, internally socnet plugin handles this event like so:

    1. Get the user who has posted the story.

    2. Get users who can read this story.

    3. Filter out users who have ignored updates for stories from this user.

    4. Get story url and snippet

    5. Compose notification and send to above users.

Some other events that can trigger notifications are 'accepted into group' and 'request received'. As of now, the notifications will be handled by COM_Mail, but there will be stubs to accommodate other notification systems.

Some hooks provided by socnet related to notifications:

  • SOC_createNotification($from, $to, $msg, $type, $urgency, $agent)

  • SOC_markNotificationAsRead/UnRead($notification_id)

  • SOC_ignoreNotifications($uid, $filter) - used to ignore notifications from user, group, agent(plugin)

  • SOC_getIgnoreNotificationFilters($uid)

Socnet API:

Other plugins can interact with socnet plugin to fetch users/groups info. Admin can allow which plugins can interact with socnet plugin. Some of the functions that socnet API will provide are:

    • Secure content through socnet.

    • Get user profile info.

    • Get users belonging to a group.

    • Get groups which a user belongs to.

    • Get permissions for content based on id and type.

    • Get permission widget for submit page.

    • Send notification to a user or group

In addition to the above hooks, we can have event hooks like:

  • SOC_saved/edited/deleted

  • SOC_goupSaved/Deleted

  • SOC_userAdded/RemoveTogroup

Timeline:

Community bonding period:

    • Discuss the core patch provided by Joe

    • Test and finalize the core changes in the patch

    • Discuss issues in the current implementation

Weeks 1-2:

    • Start a plugin and create pages for opting in to socnet, group management

    • Implement handshaking for membership and add/remove users

Weeks 2-5:

    • Design database structures and security code for socnet permissions

    • Implement hooks to get/save socnet permissions

    • Implement permission check for a given user and object

Weeks 5-8:

    • Design notification database structure and code to send/receive notifications

    • Add email subscription to notifications

    • Implement notification filters to prevent annoying notifications

Weeks 8-10:

    • Check security in features provided by the api

    • Identity any other api features that can be provided

Week 11:

    • Test integration of all feaures and fix issues that may crop up

    • Documentation

Week 12:

    • Grace period

Notes:

I have 7 evaluation components between May 24th and June 18th. I may require some time during that period. But I will make up for that time after June 18th as my term ends that day and I will be available throughout.