> > One question about your activity streams support... do you use it only > for microblogging or are you also transferring other kinds of data? >
No. We are 'objects agnostic'. So, today you can share status, pictures, links, etc.. using the basic activitystream objects, but you could also use a specific client (e.g. social shopping list application) that shares specific objects that you have defined in your namespace (e.g. shopping list). Up to you then to drive standardisation of your object model (not sure if the AS people have a process for this yet). If I get such an activity of you, and my client does not support that object format, it will fallback to the basic elements like title and content to render it to me. We could also introduce hierarchies (Generic -> Post -> Blog Post -> Scientifc Paper), so the clients can fallback. Also, for what i read, looks like you use PEP for distributing > microblogging, have you considered using full pubsub for handling other > situations? > We are in fact more doing something like PubSub on a JID. Which makes perfect sense for user activities. We are however also pushing all the public updates to a regular pubsub node (providing a firehose of the public streams). PubSub could also be used for groups. > 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 > > You also need identifiers (and there is a challenge to reconcile them accross these various platforms) and security (server to server federation in a pure RSS/PuSH world is not there). > 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. > To my current knowledge, Salmon is indeed a 'hack' to solve this identity problems. I don't see why all this is not bundled in PuSH (I get my updates from PuSH, so why can't I comment back via the PuSH node directly ?). But in the end... how do I authenticate (in an entity authentication sense) to the PuSH node ? That is a big piece missing at this stage in the HTTP world, and where XMPP really helps. > For establishing the social network, friendships and social acls, the > following approaches tackle this: > * xmpp (maybe with Social Relationships extension?) > Our spec for this is really fresh and needs iteration. However we don't see this as a priority since the privacy is better managed unilateraly (you put people in list and give different access to different lists). Bilateral relation setup is really just a nice to have, used by people to brag about their social graph (hey, I'm friend with Demi Moore and she confirmed it !). Let me insist on this: In our model, you don't need to setup relation to access data. Anyone can subscribe to you, but you decide unilateraly of who can see what. You can even authorize someone to have access to your content without his knowledge (e.g. I've authorized Demi to see my holidays picture, and if she evers check my profile, my server will serve her these pics, based on her ID) Hope these short explanantions help. Feel free to comeback with any questions ! Laurent
