Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

interoperability clarifications #134

Closed
anarcat opened this issue Oct 5, 2016 · 4 comments
Closed

interoperability clarifications #134

anarcat opened this issue Oct 5, 2016 · 4 comments

Comments

@anarcat
Copy link

anarcat commented Oct 5, 2016

pump.io and gnu status are mentionned in the "acknowledgements" section, but it is not clear to me if the new standard will cleanly interoperate with those existing implementations, let alone other protocols like Diaspora.

it would be nice to clarify how interoperable the protocol will be, and if not, what are the changes that make it incompatible with other protocols.

@cwebber
Copy link
Collaborator

cwebber commented Oct 21, 2016

I don't think things will cleanly interoperate directly (aside from with Linked Data Notifications). ActivityPub is closest to the Pump API and will even then require some tweaking to get implementations to work (a switchover from AS2, etc).

There are so many protocols, I'm not sure it's possible to do a complete survey without making ActivityPub much, much longer than it already is. However, we link to the Social Web Protocols document, which does do this? Granted, not for protocols outside the group...

I wonder what @rhiaro thinks?

@cwebber
Copy link
Collaborator

cwebber commented Apr 7, 2017

Okay, @anarcat raised something like this again on pump.io and I responded there:

ActivityPub isn't aiming to be a standard that "bridges" interoperability across all existing instances without any work. It's a standard that people will either have to port to or bridge to. It's heaviliy informed by other standards, and we worked hard to get feedback from other groups... a number of decisions in ActivityPub happened due to feedback from talking to Friendica and Diaspora devs, for instance. And of course we've been working with linked data people.

ActivityPub is well informed, but it isn't magic pixie dust where it automatically makes interop happen. Recently I've been studying a lot of lisp history; that's also a place where many languages diverged. There is no magical route. Common Lisp was an effort to try to bring interoperability amongst the various lisps, and I think is probably the most successful language interop effort of all time; in that case, much of the code that existed did work with realtively little porting, but code did need to be ported. The good news is though, you can write lisp code today that applies to a large number of lisp implementations which have adapted the Common Lisp language... and those are the only languages in which lisp interoperability is easy. But of course there are a lot of lisps which don't do that, and even my favorite (scheme) is not common lisp interoperable, and barely interoperable between its own implementations.

Will ActivityPub be the Common Lisp of the federation world? It would be great if it were. We could even build tools that will allow interop to be easier through bridging. But the best routes will happen due to porting. We've tried to be as informed as possible by all the federation implementations out there, but it hasn't been easy... even getting people to review and be part of the process was a large portion of what I did early on. But we studied all the major standards that were out there.
I'm not sure what answer you're looking for though. I don't know what result we will get. If ActivityPub could be to federation standards to what Common Lisp was to lisps in the 1980s, there may be hope for the federated web. I don't have a crystal ball to know... all I have is our efforts.

But as for:

shouldn't we aim to interoperate all that stuff? it seems really unreasonable to have (what) 5 different standards for this stuff...

Then yes, if ActivityPub can be the Common Lisp of the federated web, then that above problem would be less severe. I don't know if it will be... I hope so.

And also note that the need for interoperability in federation is even more severe than the need for interoperability in lisp. In a language, at least you can in theory just use one implementation. Federation is all about interoperable sharing of state. So if we can't achieve that, I agree that we're in trouble.

I hope that answers some questions in this thread, though I don't know how to fit that into the standards document.

@anarcat
Copy link
Author

anarcat commented Apr 8, 2017

i guess what i was hoping for is to have an estimation on the "semantic distance" between the standard and existing implementations. for example, i assume that ActivityPub is similar to ActivityStreams, so it would be nice to see how they differ...

but i understand if this is considered out of scope.

@rhiaro
Copy link
Member

rhiaro commented Apr 10, 2017

Hey @anarcat, I'll certainly aim to answer your questions in Social Web Protocols. ActivityPub and ActivityStreams 2.0 co-exist (ie. AP uses AS2 as the data format for the protocol). SWP focuses on the specs of this WG, but I'll do my best to do a brief survey of other related specs, perhaps in an appendix.

I'm gonna close this for now. Feel free to raise other issues along these lines on https://github.com/w3c-social/social-web-protocols instead

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants