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.