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.

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.

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.