Drupal Social Initiative (Social API)

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!


  • The goal of the Drupal Social Initiative (Social API) is to harmonise Social Networking functionality in Drupal; provide more functionality to end-users; provide easier site creation and configuration to site administrators and developers; and enable easier module maintenance for developers.
  • Add more ideas...


  • Provide a common interface to access common functions across multiple social networks. Making it easier for:
  • Developers to create and maintain social network integration modules.
  • Site builders to utilise social network integration modules that harmoniously work together.
  • Users to access social networks functionality.
  • Let's work on clarifying these objectives over the next few weeks leading up to the Abstracting Social Networking functionality in Drupal sprint.
  • There are numerous modules for Drupal social networking integration.
  • Connecting with other networks
  • Pulling in content
  • Pushing out content
  • What else?
    Abstracting Social Networking functionality in Drupal stack


  • HTML data (meta tags / microdata / opengraph / facebook)
  • identity / authentication
  • importing data - relationships / likes
    • storage in Entities - User relationships / Flag
    • exernal db
  • posting
    • direct
    • user fulfilled
  • elements on page, e.g. facebook likes
  • Social network apps
  • building social networking function directly in Drupal

User/Developer Stories

  • Add your personal stories (as an end-user, site administrator or developer) as to what you want to see happen in the Drupal Social Initiative. Also, how do we want to interact/integrate with external social networks?
  • j0rd: for each site I make, unfortunately clients always want social shares. My problem is any third party plugin embed can/will destroy front end performance. What I need is an addthis type JavaScript to embed the 3rd party shares with best front end performance and ideally have a nice drupal back end to deal with the Meta title / description / image / movie headers.
  • dahacouk: Social Media Dashboard – Aggregate all my activity and my friends' activity from all my social networks into one dashboard where I can configure the display of that information.
  • Download friends' lists
  • Posting/sharing to pages in external social networks
  • dahacouk: Import Facebook groups wholesale into Drupal?
  • [AIGAIJ] Strong consideration for how to handle internal corporate and/or protected social networks. Corporate initiatives may leverage drupal to cross the inside-outside social experience and include interface to other platforms. Educational organizations may do much the same, with similar requirements for privacy and protection of content, users, and systems. Target state may be a separate stack within the DSI diagram to afford for these types of integration.
  • What else?...

Future directions (need to add website links)

  • Federated social networking
    • WebID
    • OStatus
      • PubSubHubbub
    • OpenSocial
      • Portable Contacts
  • What else?

Collaborative tools

  • This wiki page.
  • IRC: irc://irc.freenode.net/#kendraio
  • ...?

Things to do

  • Contact module developers in a couple of weeks when we've honed the Drupal Social Initiative plan?

Code review

  • We should be able to abstract these into a social networking API
    • OAuth for authorisation
    • Pluggable layer for
      • Notifications
      • Pulling in and using content
      • Posting to other networks
      • What else?

Playing nice

  • We need to play nice with current social network integration modules and work with maintainers to decide how we can best abstract functionality for common tasks.

Leveraging existing work (need to add more modules)

  • Table of (all?) Drupal 7 (or soon to be) social networking modules with their maintainers so we can get an idea of module functionality and easily contact their maintainers.
Realm (network, protocol or area) API Module name Maintainer names Drupal version Date maintainers contacted Comments
Social network --- --- --- --- ---
- Social media TomDude48 7 - -
Facebook Facebook social plugins integration ferdi - 2012-06-10 -
Facebook Drupal for Facebook Dave Cohen - 2012-06-10 -
Facebook Facebook Connect vectoroc, jcisio - 2012-06-10 -
Facebook FBOauth quicksketch - 2012-06-10 -
Facebook Facebook Like Button jerdiggity 6, 7 - -
Google+ Google+ rszrama - - -
Google+ Google +1 Plus One and Badge corbacho - - -
Twitter Twitter juampy - 2012-06-10 -
Twitter Twitter Block ZenDoodles - - -
Twitter Twitter Timeline mrfelton 7 - Uses Bean module
Twitter Tweet IceCreamYou 7 - -
YouTube Youtube API beeradb, aaron 6 2012-06-10 Seems stalled?
LinkedIn LinkedIn Integration bellesmanieres 7.x-1.x-dev - -
Gravatar Gravatar integration Narno 6, 7 - -
- Follow q0rban 6, 7 - -
Authentication --- --- --- --- ---
OAuth Connector voxpelli, Frans - 2012-06-10 -
OAuth OAuth juampy - 2012-06-10 -
OAuth OAuth API Sylvain Lecoy - 2012-05-28 -
Mozilla Persona Mozilla Persona donutdan4114 7 - -
Semantic Publishing --- --- --- --- ---
schema.org (Google+) Microdata linclark 7 - -
Open Graph (Facebook) / Twitter Cards meta tags Dave Reid 7 - -
Open Graph Open Graph meta tags hiddentao 6, 7 - -
Open Graph Opengraph Filter Frans 7 - -
Internal --- --- --- --- ---
Drupal Service links TheCrow - 2012-08-22 -
Drupal Social Share willvincent - - -
Drupal User Relationships berdir - 2012-06-10 -
Drupal Flag Friend sirkitree - 2012-06-10 -
Drupal User Relationship Locator mrf - 2012-05-24 mrf wants IRC during sprint
Drupal Heartbeat Stalski - 2012-06-10 -
Drupal Statuses icecreamyou - 2012-06-10 -
Drupal Invite smk-ka - 2012-06-10 -
Drupal Private Message berdir - 2012-06-10 -
Drupal Message Amitaibu 7 - -


Posted to

abstracting-social-networking-functionality-in-drupal-stack-2.png60.68 KB
Drupal_Social_Initiative_Social_API_Stack.png104.19 KB
social-stack-sun-barcelona-june-2012.jpg88.26 KB


I added OAuth API module and

Sylvain Lecoy's picture

I added OAuth API module and I think you may be interested for your initiative. It mainly differs from the OAuth module because it is extensible, you can choose the low level library (PECL OAuth, PHP OAuth, whatever...) and the system uses Drupal Entities called 'Application'.

Each application has an ID, and the authmap is re-written to handle multiple applications per user. So you have a key(oid, uid) with oid the OAuth Application ID.

I made the choice of not contributing to the OAuth module because they rejected my proposition of extends the module to support native PECL library. Also, the core drupal authmap is not really usable and this modules corrected the architecturing problem reported here (http://drupal.org/node/817118, and http://drupal.org/node/920908).

Abstraction of core and contribs

Stalski's picture

HI all,

As maintainer of heartbeat, I suffered in d6 because I had to get integration myself for any modules "I could think of" in heartbeat. E.g. all friends modules(flag_friend, UR, friendslist), the modules who split up content by access (Organic groups), shoutmodules (statusses/fbss, shoutbox).

I tried to abstract the way I needed to "know" things from those other modules.
I came up with API framework which ended up by calling something like:

APIFramework::getInstance()->invoke("get_friends", $userA)

I did not persist since all maintainers would need to have some integration in their modules. In my opinion this could only be good since important methods are abstracted in the modules. In technical words, were APIframework only delegates the question to the module who can leverage the answer and where the invoker does need to know who's giving the answer.

Since core initiatives where already trying to add context to drupal and have some abstraction, I stopped looking at it. It seemed as people where not that interested (some exceptions).

So, dunno, check that old code and see if my thoughts can help you. I am also here if you need me :)

  • Edit - Just checked that project page again and it seems I did a layer in between to handle the type of request, so a handler like "user relations" (who's going to take care of questions of that type) ...
    That might be skipped in general depending on how the invocation methods are stored.

Some questions, thoughts.

Dave Cohen's picture

When I look at the image posted (abstracting-social-networking-functionality-in-drupal-stack-2.png), I think the top layers are upside down. Right?

To be clear, is the problem that social network modules need a layer on top of drupal core to make integration easier? If so, that "layer" should be baked into drupal core - for easier integration by any module, social network or not.

Or is the problem that third party/custom modules need a layer to make social network integration easier? That is, an API that says "get this user's friends" without caring whether the user's account is linked to twitter, facebook or google+ (or... all three). I think this is what you're talking about here, which I would draw as a layer on top of the facebook, twitter, google+ modules.

Also that image shows "AAA Abstraction", which I'm not sure what that stands for.

I think that no matter how much work is put into an abstaction layer, there will always be things that are so specific to one social network or another that custom modules should always be able to access the underlying APIs. It would be a mistake to prevent a module from directly making say an FQL query to facebook because the abstraction layer provides something similar.

Here are some things that I suspect are facebook-specific, although I'm not expert in all the platforms.

  • OpenGraph metadata. These are tags embedded into some pages served up by drupal. Although they co-opt the word "open", I think facebook is the only network using this data. Some of the tags are decidedly facebook-specific like an application ID number.
  • Canvas page and page tabs. This is where drupal serves content to an apps.facebook.com/something/.... page, or as a "tab" on a facebook fan page.
  • Timeline activity. While a facebook wall post is similar to a twitter post, timeline activity is more complicated as it has an actor - action - object (subject, predicate, object) structure. Action can have start times and durations.
  • That's just a few, I'm sure I will think of others after I post this.

Also to think about...

Any abstraction layer should have a PHP (server side) component and also Javascript (client side) component.

It's possible to be connected to facebook and be anonymous to drupal. Bad idea to build in an assumption that a user connected to a social network is always registered on drupal.

Some social network integration is user-level, i.e. the current user is right now connected to facebook. Other integration is admin-level, i.e. the administrator generated a token that allows new content to be published to facebook fan page (even when the current user is not connected to facebook).

The facebook platform is sprawling and always changing. It's been really difficult to keep up (i.e. Drupal for Facebook is chronically lagging behind). And it seems to grow whenever a big customer of theirs needs something new. You simply won't contain everything in an abstaction layer. This layer should choose what is common enough to all social networks, or just what most drupal sites need, and focus there.

I'm not just trying to say this shouldn't be done. I think an abstraction layer could work great for a lot of uses. I totally get it. I just think there will always, at least for facebook, be things the platform can do that the abstraction layer would not. As for Drupal for Facebook, if there's a set of APIs it should implement to make the abstraction layer possible, then great! I'd be happy to help. (Especially if that help is to review a patch that already does it all. :)

Also I'm insanely jealous. I can't think of a better place than Barcelona to discuss this!

Baby steps

juampynr's picture

I suggest to go in little steps. Mainly because of the following:

  • As Dave Cohen suggests, the APIs evolve constantly and it is a time consuming task to update our wrappers and test them. On top of that, people is always asking for bug fixes, feature requests or simply some feedback, so adding an abstraction layer would make thinks even harder and slow down the rest of the issues.
  • There was a nice initiative that someone made at the Twitter's issue queue suggesting to homogenise the Post to... dialogue within the node edit page. We could write a Social Networks module that invokes a hook so social network plugins can add their fields and validate/submit handlers here.

At Barcelona we could build a list of candidate features that could be grouped between social networking modules.

Organic Group could be used

JohnnyX's picture

Organic Group could be used to build Google+ Circles (instead of boring friendlists) and also FB like Fanpages or simply user groups...?

Rough notes from sprint

dahacouk's picture

After a hearty lunch of sea food paella we got down to the sprint. Present for the first few hours were carsato, chia, dahacouk, juampy, klokie and plopesc. With jbrown making a serendipitous surprise visit at the end of the day.

Here are rough notes from that paella fuelled session. We'll need to move some of the salient points to the wiki page to keep it up to date.

  • Initial idea: it's just a controller. Nonexclusive abstraction layer. This should help some of Dave Cohen's concerns. It seems clear that this idea could go big (in a number of directions) but we should start small. For instance we could initially focus on a consolidated UI for some socialmedia modules.
  • We could aim to generally promote/focus/foster abstracting social networking functionality across all contrib modules. However, this may happen on a network by network basis rather than over all social networking modules. For instance, perhaps all Twitter modules share a common Twitter abstraction layer.
    • jbrown said "There could be an abstract class for OAuth for services that utilise OAuth. Other services would just have their own class."
  • A social API could impact a number of user types: user, site administrator and module developer. And also either UI or social networking low-level communication.
  • We are talking about bidirectional integration with social networks: pushing stuff out from Drupal and pulling stuff in to Drupal.
  • We need to be able to deal with multi-accounts per service and per user.
  • Take into account multilingual use cases.
  • OAuth module needs to be able to support multiple OAuth libraries. There's an issue – find it. Talk to sun and Sylvain Lecoy.
  • Take into account authentication limits per IP address and per user per hour.
  • Desperately need a Drupal queuing system. Is there a "standard" way being adopted by the community?
    • Be able to see the queue and what has been sent or not sent.
  • A virgin Social API module has been set up on d.o. We'll be able to add other maintainers when darrenmothersele gets back online next week.

    • How would we deal with complimentary module naming: social_api_*? For instance would our abstracted Twitter layer be social_api_twitter? Or would that create names that are too long? If so do we want to rethink naming?
  • Hooks for:

    • Authenticate
    • Post
    • Sign-in
    • Friends
  • Menu: Profile > Social networking settings

    • Choose your social network to authenticate
      • List of social networks with delete and authenticate (green tick if already authenticated) buttons.
      • User presented with drop-down menu of all social networks with an add button and submit
  • More specifically, we (eventually) want to cater for functions:

    • Sharing content
    • Following users (also subscribing to pages)
    • Post status/message/event
    • Get friend list
    • Post event - option to user post this as an event or as a normal post
    • Post track to music social network – admittedly most of the functionality will be in a "plugin" contrib module
    • Import: Friends, tweets and comments about subjects/pages, events
    • Delete posts/tweets?
    • Recurring posts like reminders
    • AddThis?
    • Multi module solution rather than one monolithic module

Next I'll upload the drawings we made...

Social BoF for DrupalCon Munich 2012

dahacouk's picture

I have set up a BoF for DrupalCon Munich 2012 called Drupal Social Initiative (Social API) to see if that will tweak some interest. It's just serving as a placeholder for the moment for us to coordinate efforts and times and places – as the time is wrong as it's during Dries' keynote!

Look at singly.com?

dahacouk's picture

We should look at https://singly.com/docs/api for pointers.

If this then that?

dahacouk's picture

We should also look at http://ifttt.com for ideas on perhaps where we should be able to go with Drupal. Using Rules to it all together?

Scheduling BoFs in Munich!

dahacouk's picture

A bit crazy to try and schedule a time for us all to meet so I've made the following bookings with a hope that we'll be able to meet at some point!

Room: Rom
Time slot: Tuesday 17:00-18:00

Room: Montreal
Time slot: Wednesday 11:45-13:00 – Lunch!

Room: Montreal
Time slot: Thursday 11:45-13:00 – Lunch!

Hope to see some of you at some point.

tomorrow lunch

juampynr's picture

I can do tomorrow's lunch. I suggest to do it downstairs at the coder lounge, where we can sit to eat.

Wednesday lunch! Done! But please Montreal for venue...

dahacouk's picture

Great! Wednesday lunch! Done! But please can we use the Montreal room for the venue? We can take our lunch into the BoF room. I just checked it's a lovely room with tables and space for a nice group. Thanks!


juampynr's picture


Munich BoF: Social Initiative (Social API)

dahacouk's picture

If you are planning to come to either of the Drupal Social Initiative (Social API) lunchtime BoFs then please come at 11:45 with your lunch in hand or get your lunch later when the queues have gone down. There's loads of food and it wont run out. The BoF will be held at the Montreal room which is really easy to get to on the "first floor" map.

Room: Montreal
Time slot: Wednesday 11:45-13:00 – Lunch!

Room: Montreal
Time slot: Thursday 11:45-13:00 – Lunch!

If you are interested but can't make it then please take a look and comment at:

Lots of great ideas came out of the BoF yesterday with pdjohnson, Marc Blumenfrucht, jbrown and I. I'll detail this shortly.

Hope to see some of you at some point.

Cheers Daniel

dahacouk's picture

The Drupal Social Initiative BoF at DrupalCon Munich at 17:00 on Tuesday 21st August was attended by pdjohnson, realitygaps, jbrown and dahacouk. Here's some ideas and action points that came up:

pdjohnson and realitygaps may be able to get hold of code and/or developer time to assist Drupal Social Initiative to meet its goals.

dahacouk added "User/Developer Stories" to the wiki page. And needs to look at how other Drupal Initiatives are structured in terms of collaboration tools. And discuss/network with horncologne aka jam.

We need to create a big plan with milestones. General agreement on being pragmatic and work on quick short term wins while keeping the larger goals in mind. Aim to start promoting plan to larger community mid September. So we have some writing to do!

dahacouk's picture

The Drupal Social Initiative BoF at DrupalCon Munich at 11:45 on Wednesday 22nd August was attended by russellb, mkostrzewa, audreyletiec, dahacouk, juampy and klokie.

We talked about...

We want to "get off" (remove our dependency ;-) from external services like AddThis.

russellb suggested we need an "add this" button that is just internally serviced by the Drupal website rather than using the AddThis service. Perhaps Service links is the one way to do this? TheCrow has been contacted.

Setting up Social Network API Teams that maintain the APIs for a given Social Network so that effort can shared. Like:
* Facebook API Team
* Twitter API Team – juampy says that he has already abstracted out the Twitter API from his Twitter module and placed this on GitHub.
* LinkedIn API Team
* Google API Team

dahacouk's picture

The Drupal Social Initiative BoF at DrupalCon Munich at 11:45 on Thursday 23rd August was attended by j0rd, guy_schneerson, iAugur, klokie, jbrown and dahacouk.

There seemed to be general consensus on the following ideas:

  • Let's keep the requirements on the general abstract side and see where common features reoccur and, if we can, not get too fixed on how we are going to technically implement all this – meaning let's keep our options open as to how we could technically implement all this – so all suggestions are welcomed into the pot at this early stage.
  • Let's also think about the technology that the Drupal Social Initiative requires as potentially being generally useful to the whole of the Drupal community whether using social applications or not.
  • Let's not get caught up in huge grand plans and never produce anything of value. So, create a project plan that has milestones and goals but these are "boxed". Decoupled and modular are useful ideas.
  • Let's try and get all of the social module developers collaborating about this process – so outreach is important.
  • Any others?...

thumbs up.....requirments

Energyblazar's picture

I like the way you guys thinking.... :D

Sun's diagram for the social stack

dahacouk's picture

At Drupal Developer Days Barcelona 2012 after the BoF I met with sun and he drew this diagram:
Social stack Sun Barcelona June 2012
Which I have almost turned into a better rendering. Feel free to complete.

I feel "the architectural design stuff and Symfony pointers" need to be expanded upon and explained.

Generally the aim is to get a consensus on the ideas (big and small) with milestones. There seems to be so many people that are willing to help. My concern is how we can best utilise all this energy and remain focused and get stuff built that works for all of us. Groovy!

Missing any mention of Web

voxpelli's picture

Missing any mention of Web Intents here: http://webintents.org/ It is the work of Google Chrome and will eventually be merged with works from other browsers who are working on moving the Share-buttons into the browser, making it possible for the user to select what services they want to have "buttons" for rather then leave that decision with site owners. This is eg. a requirement for a truly decentralized social network to work - if every person would have their own instance site owners would have to add an absurd amount of buttons to support sharing to everyone's sites ;)

Regarding modules: I myself am not an active Drupal developer anymore, but I do very much agree on the general abstraction and that was exactly what I tried to achieve with the Connector modules and what I hope that others will carry on. My idea with the Connector module was that it would be the glue needed for managing connections to external accounts in a unified way so that eg. a "share"-module could have a unified way of asking for accounts and interact with them. Thanks to the OAuth Connector almost all OAuth API:s are supported - one can add a new connector through either the UI or through a default Connector provided by either OAuth Connector itself or preferably through eg. a Twitter module or a site feature.

I would suggest bringing this thread to the attention of the Connector issue queue if you haven't yet and the OAuth module issue queue as well and if you feel that you don't get any responses from either then ping me on Twitter, @voxpelli there, and point me to the issues and the suggested fixes there and I can probably add you some of you as some kind of co-maintainer of those modules.

Thanks for the

klokie's picture

Thanks for the recommendations - I wasn't aware of Web Intents, which looks to be very relevant to the goals of this initiative, at least for use cases that involve pushing out content or activity to individual services. Also the OAuth Connector and related Connector modules are totally in line with the concept Daniel has described, allowing a pluggable abstraction of the authentication layer upon which another layer for service and graph abstraction could be built.

Thanks again for the pointers - I'm looking forward to seeing what sort of momentum we can generate.

wordpress social media dashboard

michee.lengronne's picture

Something similar to that :


can be good also.

User story?

dahacouk's picture

Yes! I think that people may want this as one view on their social dashboard. Could you describe in words what the "user story" is for you? What's the requirement?

Drupal Social Initiative venn diagram

dahacouk's picture

I've been toying with the possible wider extent/scope of the Drupal Social Initiative. And I created this venn diagram:


It's not totally accurate by any sense. Just trying to lay out the land.

What do you think?

Prefer open APIs

skomorokh's picture

Using something like OAuth Connector (or Hybrid Auth) that implements OAuth within Drupal prevents third party JS stuff that likely gathers info on user behavriour across sites.

Similarly, the OExchange protocol can be used directly to link to other sites in order to share posts.

It would be nice to have a "no third party scripts" function where external resources are only only contacted when you use them and only the service you choose.

Notes from the DrupalCamp London 2013 BoF...

dahacouk's picture

Here are notes from the DrupalCamp London 2013 BoF (Saturday 02/03/2013 Room C167)...

Great news! Kendra Initiative potentially has some serious money (100K GBP promised by UK's TSB if I can raise 80K GBP) to build Kendra Hub – Media Asset/Content Management, Semantic Syndication/Promotion and Commerce Tool
Kendra Hub needs everything that the Social API ecosystem will provide. In terms of time scale I need to raise the money in 4 months to qualify. If you are interested this funding comes via Celtic-Plus approval:
But enough of that!

Let's start issues http://drupal.org/project/social_api
Using this project as a placeholder and not necessarily the ultimate name for the module/whatever – to be decided by us.
Separate business/strategy, use-cases/requirements and technical/architectural requirement with components.
Darren added George Boobyer – iAugur (http://drupal.org/user/750068) as project maintainer.
Darren added Guy Shneerson – guy_schneerson (http://drupal.org/user/755184) as project maintainer.

Guy suggested for us to target Drupal 8 for all this work. All agreed.
Alex McFadyen suggested talking to Web Services and Context Core Initiative (http://groups.drupal.org/wscci) about methodologies.

Look at http://www.gigya.com and http://janrain.com.

Set up sprints at DrupalCamps and DrupalCons and elsewhere to do a big push at Prague 2013.
How do we deliver the results of the work? Modules? Features? Install profile?

So we'll continue with wiki pages on g.d.o in tandem with issues on the d.o project page. Keep expanding the wiki page as a kind of plan with use cases and mile stones to serve as a document that we present to the wider community. So chip in do. We all then post RFCs to our own contacts and people we think should be involved/aware.

And any help with diagrams and descriptions would obviously be great to bring clarity and structure to what we are trying to achieve.

And pass this on to others you want to bring in now – who could help with initial ideas – why not?

great news!

Mumonkan's picture

daniel/dahacouk - very interesting developments, to be sure. i will be watching this closely, as i am working on a site that will be needing lots of social hooks eventually. (but it will be in d7 at least to begin -- and i understand targeting d8 instead. insert rant about speed of drupal cycle we have all heard before here. etc.)

i am currently using janrain (and have experience with gigya from a previous job, albeit light). my usage of janrain is not complete enough to be that useful so far, but i will try to pipe in with my 2 cents when i can. (aside: janrain is in portland where i live -- and also where u.s. drupal con is in a couple months -- not sure how useful this is; but anyone let me know if you are going to be in town! :) )

short version: i will be watching and will try to help out where/when i can. likely if anywhere, it will be on the google stuff, as that is where i am focusing my energy presently. (e.g. g+ "app activities" [was "history" api], youtube api 3.0 integration etc.) ... but sorry i will more often be lurking. know i will be rooting for this from the sidelines though.


  • hookfoo : drupal module consultancy : portland oregon

Please join Drupal Social Initiative on g.d.o!

dahacouk's picture

Hello All,

We've been making some progress on the whole Drupal Social Initiative (Social API) front. We want to get some infrastructure in place for the buildup to Prague. Then we'll be able to do some more outreach and run some sprints, etc. To this aim I've created a group at:


It is submitted for moderation. As you can see from


A moderator, Scott Reynen (sreynen), is asking for me to "demonstrate interest".

So, please do join the group ASAP and invite anyone else you think may want to be involved.

Many thanks!

Cheers Daniel

Hello everyone, I have just

Leon Kessler's picture

Hello everyone,

I have just seen this, as I am planning on attending the BoF at drupalcamp London http://2014.drupalcamplondon.co.uk/content/drupal-social-initiative-soci...

We've been creating a Social Content module within our agency, that has now gone through several iterations and is on version 2. The project can be found here: https://drupal.org/sandbox/leonnk/2207943
It's still being developed (hence the sandbox version), and has just had a bit of a rewrite to a new object oriented structure.
It basically still needs a lot of work, but would be interested in collaboration now that I have found this group.

I've set the time for the BoF

dahacouk's picture

I've set the time for the BoF to be Sunday, March 2, 2014 - 11:35 to 12:00 Room A109

I missed the bof :-( (I

Leon Kessler's picture

I missed the bof :-(
(I thought the bofs all started at 2pm).

Anyway, will keep my eye on this group and see if there's anything we can help or collaborate with.

Is there a module that is being worked on?

Hi Leon the BoF ended up

guy_schneerson's picture

Hi Leon
the BoF ended up clashing with another BoF so you haven't missed out :)

Google funds Drupal Social API...

dahacouk's picture

I am extremely excited to announce that Google has just announced that it is funding Valentin Sánchez to work on the Drupal Social API via Google Summer of Code (GSoC) 2016:

I've set up this Google mailing list to celebrate:

And here are some other ways to participate in the project:
Google Drive: https://goo.gl/YDvjxL - See "Read Me First"

Please invite Drupal users and developers who you think would be interested in helping the Drupal Social Initiative to create the Drupal Social API.

Cheers Daniel

Social Networking Sites

Group events

  • 2018-07-02 (All day) - 2018-07-06 (All day) Europe/Lisbon
Add to calendar

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week