Also worth a look.
The thread over at http://loom.io/discussions/1017 just increases my support for OStatus.
And decentralized app authentication? That’s OAuth (or if one dares, OAuth2). Just add it to the mix and OStatus has a defined way of letting third-party apps access specific data and
A very important problem that may arise when discussing “what data is available” for remote apps is the standardisation issue. Given that everything in OStatus is modeled around ActivityStreams (which closely matches Facebook activities) - Tent.io has to model along these lines or it will make interoperability harder.
Given that Tent.io uses Activitystreams for activity modeling, I guess it won’t really matter what direction interoperability takes, as it’d just be different means of feed pushing or API endpointing.
Also, I have no idea where that “just microblogging” stuff comes from. OStatus is far more extensible even in its current state. The protocol allows for users, groups & pages - and subforums for each of these entities and whatnot.
If a certain instance doesn’t support the specific application, likely it would just throw it away or handle it in a more basic manner (like subforum relations might go away but each ostatus:attention will still receive a representation of the post/thread)
Mikael, please check this thread, one of Tent’s core team members explains why they didn’t go with it. It’s not like they’re saying that OStatus and ActivityStreams are bad, it just means that there are design limitations to both, and to better suit their needs, they decided to rewrite from scratch, basing their ideas on concepts they liked. It’s been said that OStatus would’ve needed some heavy refactoring to support what they wanted to do.
Mikael: Great to see you here. 
I can’t judge the details being discussed, but as said, I think this discussion is important and I’d love to see more status.net dev involvement. Wether OStatus OAuth or Tent.io: it would be great to get this solved with all parties involved.
tent is basically a dropbox for json and files. You put things in your “folder” share it and it gets replcated to the folders of your friends. They can interact with it and these interactions get synced back. Thats a very simple concept a lot of peope understand.
In that way tent offers a hirarchy of complexity. As a user you dont have to understand more than this conecpt. As a developer for apps you have to understand only a little bit more, but it still is about as easy to do something as with twitter. Then only at the server level you have the full complexity, which you can just leave to the nerds.
For Ostatus i don’t see a simple concept or a hirachry of complexity. In Ostatus every participant of the network speaks to everyone with an abundance of protocols. Every protocol has its own concepts. Its hard wrap your head around all of this, privacy and files even being out of scope.
A protocol should provide a solid platform with simple mechanisms, that circumvent as much complexity as possible, even at the loss of versatility. The reason we are stuck with email is not, that we did not come up with something “better” but because we did not come up with something “better” and as simple as email.
I know we are quite off the original topic right now. But your comments (especially Flaburgan and Julian) here made me think a lot about compatibility with email. SMTP is probably not best for building a social network upon. But the original topic was “interoperability with other social networks” and we should probably have a serious look at email there.
I wrote three pages down describing how my ideal social network would look like. I focussed on ostatus, but I am not a fundamentalist there. If there is something more useful, we could exchange ostatus with that in my draft.
Hello, I’m Jaussoin Timothée (aka edhelas) founder and main maintener of the Movim project. I’ll follow your discussion and answer all the questions you can ask about Movim and more generaly XMPP. So please don’t be shy, I think we can built beautiful things together
There’s a lot of politics involved in this whole thing. Everybody is doing their own thing and in the end no one ends up as compatible with anyone else. Things are just not working this way.
What I would like to see in the future is an open standard that is completely agnostic, or to put it more precisely, a standard that would support anything, like, everybody is doing their own thing, but also have an interface to talk with others. If you know what I mean. How about that?
I dont think that would work. To attract developers as well as users, it needs a solid basis, which just does what is says, so anyone can build on top of it. Not a loose web of interfaces, where you don’t know in the end who received your message and who didn’t.
XMPP could be such a solid basis. I don’t know enough about it. Buddycloud is also using it, together with Activitystreams.
To me it seems like HTTP and XMPP are quite reasonable transports for the job, no argument there.
In the end it boils down to what exactly is exchanged with them.
Sure, XMPP has a lot of the whole ‘status’, ‘contacts’ and ‘message’ stuff already built-in, but I don’t see any shared-hosting providers letting you set up a server for that any time soon.
In that regard HTTP is the more flexible transport, since hosting opportunities are out there en masse.
In my opinion it would be ideal if we could - some day - exchange the data with both transports (best effort/fallback).
As for the content … that’s really hard. We’ve had a few mentions of Protocols that try to improve upon ActivityStream, but none of them really can be considered “the next thing everybody will use” or even just “that’s exactly what we need”.
So either we go ahead and join forces with the separate projects one by one as we have resources to do so, write adapters and become like Friendika (which I would not favour) or focus on becoming a driving force behind pushing a common, expandable and - above all - easy protocol.
It’s just code, nothing can’t be changed 
Yeah, I’ve been thinking about XMPP too, and it seems like it is a solid platform we could rely on.
How about making some sort of interchange servers that would be much like DNS, pod administrators could run their own XMPP server or they could use some other for information exchange? That way, if someone is following a specific hashtag, for example, could see all public posts from all pods, no matter whether the actual pod users are connected with each other. Speaking of that, it could be a completely decentralised network with XMPP exchange servers functioning much like DNS root servers and everything would be truly decentralised in nature.
@Timothée : I know you build Movim on XMPP. Can you talk about it and about Moxl ? What were the issues you find using xmpp ? What had you added on Moxl ? We need your experience dealing with it.
Hello Everyone.
Realize this is a very old thread, but this problem has still not been solved and found it helpful while doing researching interoperability between social media applications.
Would like to share a recently published white paper on this subject. Hope it adds to the discussion.
Briefly:
We think that aligning incentives toward cooperative competition is generally preferable to regulation, and in this particular case, might help to avoid the inevitable problems and unintended consequences that would almost surely follow any such attempt to regulate social media.
Our goal is to enable and encourage smaller social media applications to interoperate, in order to combine their network effects and challenge the monopolies. But companies across many industries are understandably reluctant to cooperate with their competitors for many obvious and legitimate reasons. We’ve proposed a mechanism design that intended to address these issues, and would appreciate any critical feedback.
If anyone would like to take a look, our full white paper is available to read at maitri.network.
Thank you.