Technology Stack (outdated)¶

• Technology Stack (outdated)
  • Contextualizing the Project
  • OpenOutreach (content)
  • Organic Groups (content)
  • RDFa and SPARQL (semantic technologies)
  • OpenID, LDAP, WebID (authentication)
  • XMPP (messaging)
  • Status.net (messaging)
  • Kune (messaging)
  • Transport Topology (messaging)
  • Additional Resources
  • Pitfalls

Contextualizing the Project¶

• A federated network in practice is a combination of:
1. content
2. semantic technologies
3. authentication
4. messaging

• This project provides a Drupal 7 install profile that provides support for assemblies, working groups and camps while interfacing with a set of services that allow end users to participate in a federated network with other similar sites
• Any part of the system could in theory be replaced by the end user. We have a Spec Sheet that should be abstract enough that a totally different implementation could surface that simply "friends" our server network to join it seamlessly
• Drupal Modules lists some of the modules that are relevant to this effort. If you have a Drupal 7 development site set up and want to know "what's next?" this page will point you to some projects that need help and a list of things that look like they can be used in production as-is
• Project Resources contains links to information and contact info
• Pitfalls we've run into
• Due to technology maturity issues with some of the more esoteric Drupal 7 modules, it may be a good idea to separate the content management interface in Drupal 7 (that is, the part that UX is focused on) from the rest of the infrastructure. A Drupal 6 implementation of the messaging layer, for example, could be more robust. A distributed cluster of such servers could form the backbone network that the Drupal 7 sites interact with via web services

OpenOutreach (content)¶

• Good starting point for providing the following features:
  • Articles
  • Blogs
  • Calendar
  • Forums
• Install profile provides example of how to support "flavors" of configuration at install time
• Need to disable forum and media features during install, enable forums later

Organic Groups (content)¶

• Works a little differently than in D6
  • Would require a subgroups model
• Should create an FGA Groups feature to support

RDFa and SPARQL (semantic technologies)¶

• Lots of links on Project Resources page
• Drupal's SPARQL support will allow querying of semantic data in a distributed manner
• Start defining a vocabulary based on what Drupal natively uses plus other existing ontologies plus extra things specific to the movement
• Development of storage via RDFDB underway - supports Drupal's default ARC2 store as well as 4store and Virtuoso
  • Core Schemas
    • Dublin Core
    • FOAF
    • SIOC
    • SKOS

OpenID, LDAP, WebID (authentication)¶

• OpenID support in D7 part of core but sketchy (do people seriously use this in the real world?)
• LDAP support seems to be stable, but not fully tested by the FGA team
• WebID (FOAF+SSL) has D6 support in this module which may be easy enough to port to D7. If so we should contact the author about submitting it to drupal.org. This module is WebID proper, but doesn't have much in it right now
  • FOAF+SSL HOWTO
  • Need to choose solutions that are either already supported by most components (LDAP) or else create a module for each component to support the protocol universally (WebID) -- This is key to any federated network

XMPP (messaging)¶

• No support in D7. D6 support supposedly good but not verified by the FGA team
• ejabberd (or Openfire) could be part of the back-end network configuration
  • D6 support tended to favor ejabberd but Openfire seems nicer, especially the admin interface
  • Need to fully explore how XMPP (think PubSub) can be used as a transport layer
  • Think servers in the back-end network "friending" each other

Status.net (messaging)¶

• Main article: Potential Architecture Using Status.Net
• OStatus technologies constitute a fully-formed messaging layer
• Instances of status.net (LAMP stack) could be part of the back-end network configuration
  • Could we manage OStatus via our own status.net instances? We would need a web service "bridge"
  • Should we start with the GNU Social extension of status.net?
  • It is possible to run an XMPP bot for status.net
    • Broken in 1.0.1 -- Does the GNU Social distro have a working bot?
    • Openfire could be good as an XMPP server if it works with GNU Social
    • Can we write a Drupal module to leverage that?
    • Is there a simpler way to do this?

Kune (messaging)¶

• Based on Apache Wave, the open-source part of Google Wave
• Java-based, like the Openfire XMPP server
  • Supports XMPP via the Emite GWT library
• Federated network solution but needs work to support WebID auth
• RDF support not believed to be present and would need to be added

Transport Topology (messaging)¶

• Need to think about message passing requirements and how to support without needing "big" servers
• Format of the message will typically be an XML payload containing the usual Atom/RSS info, relevant service endpoints (Webfinger, Salmon, etc), RDF metadata, Activity Streams info

Additional Resources¶

see also: Primers and Tutorials

Pitfalls¶

• OStatus support is non-existent for D7
• Quite a few useful modules for D6 are not ready for D7 or are in beta but could use more testing
• Debut Media and Debute Forum seem to cause problems for OpenOutreach in its default configuration unless disabled until after install completes