social-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Social-discuss] Onesocialweb source code and federation


From: Pablo Martin
Subject: Re: [Social-discuss] Onesocialweb source code and federation
Date: Wed, 14 Apr 2010 21:02:07 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7pre) Gecko/20091214 Shredder/3.0.1pre

On 12/04/10 15:47, Laurent Eschenauer wrote:
> Hi everyone,
>
> Just a small email to let you know that we released the first version
> of onesocialweb today. So you should now be in a position to setup
> your own XMPP Openfire server, install our plugin, and you will be
> part of the federation. Just keep in mind that this is a very first
> release and many pieced are not yet in place.
>
> http://onesocialweb.org/download.html
>
> In terms of goal, I think we are well aligned with the current
> discussions happening on this mailing list. When you guys move forward
> and start specifying a protocol, we'll happily contribute and
> implement if possible. At this stage, our federation protocol is based
> on XMPP.
>
> http://onesocialweb.org/docs-protocol.html
>


Looks like a very interesting approach :).

At the lorea project we are developing ostatus support, which also
includes activitystreams for which I am making the mapping for elgg.
Ostatus uses pubsubhubbub as a pubsub mechanism for notifications, but
it only handles public data for the moment. We also like to support
xmpp, so we'll see how we can interact with onesocialweb properly. We
have some experience with xmpp and also right now we're looking at
integrating psyc support,its server also speaks xmpp.

One question about your activity streams support... do you use it only
for microblogging or are you also transferring other kinds of data?
Also, for what i read, looks like you use PEP for distributing
microblogging, have you considered using full pubsub for handling other
situations?

Another close approach is to work on rdf using foaf as starting point...
looks like activitystreams also have an rdf "mapping" so we'll be 
looking into adding elgg support for rdf activitystreams with some
sparql endpoints so we can start using elgg as a kind of datawiki.
Melvin is also working on this at the site he setup for gnu social.

So, after thinking about it and as a bit of braindump, i think this is
more or less what i see as working current techniques for federation:

- Model
  * activity streams (and children... media, xcal, geo...)
- Serializations:
  * atom
  * rdf
  * rss
- Pubsub mechanisms / transports:
  * pubsubhubbub
  * xmpp
  * psyc

Then, for merging changes upstream and distributed interaction, there is
"salmon" which i think is only used in http and maybe only makes sense
there? We still have to implement this but looks like something no-one
else considers it like this.

For establishing the social network, friendships and social acls, the
following approaches tackle this:
  * xmpp (maybe with Social Relationships extension?)
  * psyc
  * foaf+ssl

Greetings

 Pablo





reply via email to

[Prev in Thread] Current Thread [Next in Thread]