Re: [Social-discuss] The Case for Branching Elgg?

[Melvin Carvalho]

2010/3/30 Pablo Martin <address@hidden>

Hi,

On 30/03/10 02:51, Melvin Carvalho wrote:

Elgg is probably the most mature open source (GPL2/MIT) 'framework'.  I assume this is compatible with AGPL.

I've looked in more detail at version 1.7 which was launched earlier this month, and it appears to have two VERY attractive features:


Restful API (New in 1.7)

http://docs.elgg.org/wiki/REST_API

This looks like it should enable server to server communication via HTTP

What you'd really want to see is the resful api working will with the MVC Controller, so I can send a request to almost any (for example user/wall etc.) page, and it will be able to pass it along to the right handler.


Global Idenitifiers (GUID)

Well they're actually local identifiers but unique to an install, so combining with the install root, they can become global.  But every object has a global identifier.

http://docs.elgg.org/wiki/GUID

I've reviewed it in more detail and I'm pretty impressed.  I think at a minimum this is a project that much can be copied from.  We can take a lot of the GNUv2 ideas and reuse, I think they've got a hell of a lot of stuff right.  It's not quite as modern a framework as the likes of symfony, and the FOAFs need work, but there's a lot of work in there and plugins that would get us quite far quickly. 

If we can get a federated social net obeying linked data principles under AGPL quickly nailed, that can give us more scope to adding fun stuff like realtime protocols, desktop integration, encryption etc. 


Is there a case for branching elgg?  Or perhaps beta testing a sample elgg community for a month or so, and see if there are any roadblocks.

At the lorea project we use elgg (somewhat of an unofficial fork like what you are proposing) so i can provide some information on that approach.

Background: We have several (mildly modified) elgg sites, and our goal is to be able to federate them by using open protocols and standards (which is why we have several independent sites), also the goal is that we don't depend on one software and most importantly, that people (us) can decide where to put their data while still being able to communicate with other people with different choices, so the protocols and data are more important for us than the framework itself. The premise being: if we can get several elgg to talk together, we can likely get other softwares to talk together -with the only added problem of diverging models.

About elgg itself. So much as i hate php I have to say i enjoy working with elgg:
 * It has an interesting model system based on entities with properties and relationships among them, most notably, you never have to think about the model and allows introspection easily. this makes it really easy to add types to the system and should make it easy to serialize to different formats as well or provide algorithmic access.
 * basic social network permission system in place so a thing can be seen by friends, some group, insiders, public. this is built in so "normal" queries will never give you something you can't see (ie, unless you acces the sql directly)
 * nice view system that makes it really easy to customize and extend through plugins, the proof being that it has a lot of plugins which basically go well together (at the lorea install we have 67 plugins 35 of which are from the core).
 * strong community

About it being the most mature framework... probably, but i think some features on crabgrass are more mature, although i'm not sure how much of a framework crabgrass is (i havent installed it or looked at the code) or if its more an application.

All in all, the framework has some things that needs to be polished, but they're not so important for us (lorea), and also the elgg people are doing a very good job at improving the framework. 1.7 solved many security issues and stabilized a lot, and for 1.8 they want to work on improving the interface system.

I've found some data on elgg release 1.8

http://trac.elgg.org/roadmap

It looks like it will be 5 months away. 

I signed up for the elgg community, is anyone a member already?
 

About protocols and formats it supports (note i dont mean all have to be supported, but i think they're relevant and we aim to get all integrated at least in some basic form to test possibilities):
 * openid: server and client working, but there are a couple things to tweak.
 * oauth: not a feature in itself, but there is a plugin providing "out of the box" oauth for user plugins (so you can easily make your own plugin that uses oauth).
 * open micro blogging: not supported, but should be easy to build over the oauth one.
 * foaf: like melvin says the views need some work but the basics are there. no foaf+ssl but the foaf you get will have the information you have access to.
 * xmpp: there is a jabber plugin which does some integration with ejabberd, but it needs some work. still, it is actually possible to chat from elgg with other networks -like gmail- which is quite nice but its not ready for production, also, the contacts are synced (although not in the best way possible). of course this is only chat; pubsub and so on lie in the unknown, but once the basic client works a lot of doors open to experiment with this.
 * email: integration of forums from elgg with mailing lists (not with the goal of federating networks, but imo since email is federated the email support is interesting).
 * rest: like you say, there is some kind of support but i'm not sure it's exactly what i'd like (i think it allows plugin to define rest actions, but i would like more something like a restful data access and modification api which is "automagic").
 * psyc: no integration yet, but we're thinking about this too, possibly trying to migrate the backend from some elgg item to psyc to see how it feels (since psyc can take care of the backend). also using it for chat instead of jabber would be ok since psyc already connects to other networks.
 * rdf: i dont see any support (other than foaf), but should be easy to build a full rdf view(rdf views for all entities) based on the generic object model (as long as you can keep it arbitrary).

Probably i forgot something... but i hope you get an idea... In my opinion, elgg is ok, but the protocols i just related are not, because not everything we need is covered there, and the specifications for the next steps after we finish implementing the current ones are basically missing (i hope we can solve that in this ml :)). At the moment i think the most we can hope is federated "identity" (openid), chat/rooms/contacts (xmpp/psyc), federated microblogging (omb), email and the foaf stuff. so, for extending the federation, i would first implement the protocols that already exist (the "state of the art"), and then see how to add other kinds (or more) of data to the mixture. Both the xmpp, psyc, foaf+ssl (rdf+acls), and omb (oauth) approach look very promising with regards to what can theoretically be done and is not done yet.

If someone wants to play around with elgg, we have a development network where we can provide access to the machine and the code (https://n-1.artelibredigital.net), also to see how it works in production (http://n-1.cc, http://redesnenred.net, http://artelibredigital.net -most are spanish networks, but n-1.cc should be usable in english).

Greetings

 Pablo