-
Notifications
You must be signed in to change notification settings - Fork 78
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
What is the relationship between OStatus, pump.io and ActivityPub? #228
Comments
Reading https://www.w3.org/TR/activitypub/#acknowledgements suggests that OStatus, pump.io API and ActivityPub are wholly distinct protocols (with ActivityPub built on lessons learnt from the earlier two). So interoperability would happen at the software layer, not the protocol layer, for example if Mastodon implemented ActivityPub. Have I got that right? |
Yes @kwill . I can see both sides to that issue. I think the hope is that AP is enough simpler and easier to work with that people will be willing to add it and eventually let OStatus support atrophy. That argument sounded a lot more convincing a year ago, before Mastodon took off, for several reasons. Probably the next step is still to see what it's like for Mastodon to implement AP. I'm particular curious how it might affect visibility of replies, boosts, etc, in practice. Those semantics are tricky. |
@kwill I'd also echo what @sandhawke said. To give some more concrete answers to your questions:
Yes.
Yes, and they interoperate because of that.
Correct. You can find details of this at https://github.com/pump-io/pump.io/blob/master/API.md. pump.io is, at its core, just an ActivityStreams distribution engine. It's actually relatively simple because of that, conceptually speaking. You might find this talk, given by me, useful. (I'm the primary maintainer of pump.io, though I didn't write it.)
Yes. identi.ca is "just" another pump.io instance, and it will federate with any other pump.io instance. I've forgotten the exact details of where MediaGoblin is (@cwebber would know), but IIRC they currently have a working client-to-server API which is basically the pump.io client-to-server API. They also have plans to introduce federation. This feature has been available in a development branch for a while, and currently federates using the pump.io protocol (there exist demonstrations of MediaGoblin servers running this branch interoperating with regular pump.io servers). However, there are plans to change this feature to use ActivityPub instead.
ActivityPub is intended to completely replace OStatus. OStatus is large and complicated (and thus a lot of work to implement). It provides a lot of features that aren't used in practice, and (AFAIK; I'm not an expert in OStatus) its model makes it difficult to do some things. I think Mastodon, for example, has had some problems implementing private messages because of the way OStatus works.
They are indeed completely distinct protocols. However, ActivityPub is very similar to the pump.io API/protocol. Conceptually speaking it can be thought of as a slightly simplified version of the pump.io stack, and using ActivityStreams 2.0 instead of the original ActivityStreams spec. In turn, pump.io's protocol and design was heavily influenced by lessons learnt from OStatus. Evan Prodromou, the author of pump.io, was also the person who wrote StatusNet (now GNU Social), so he had a lot of experience with the pain of OStatus when writing pump.io - OStatus' complexity is one of the reasons pump.io's distribution model is so simple. Again, this talk goes into these details. Hope this helps clear up some of your confusion. |
Also, I'm not sure I understand what you mean when you say:
Can you clarify what you mean by "software layer" and "protocol layer"? |
I take that to mean that interoperability would be provided by having each server speak multiple protocols. This is in contrast to having servers able to just implement the protocol they want, but they still talk to each other because the how the different protocols are designed. That kind of protocol interoperability is great, but it constrains the design a lot; basically you have to keep making things more and more complicated, never simpler, so (as you say) we didn't want to go that way here. |
Thanks so much for the informative answers. (Re. layers, yes I was trying to distinguish between a server speaking multiple protocols, and a protocol that interoperates with other protocols. I'm anticipating a near future where I'm running a server that needs to federate with ActivityPub, OStatus and pump.io servers.) |
@kwill ah, gotcha. Yes, it interoperates at the software layer, not the protocol layer. Do note, however, that generally speaking OStatus is considered "legacy" by the Working Group, and we'd like OStatus servers to migrate to ActivityPub. pump.io will be migrating too. |
For the record, Mastodon implemented ActivityPub soon after this discussion.... 😄 |
My understanding is that:
How do these protocols interoperate? Does ActivityPub completely replace OStatus, or only the Activity Streams component?
Cross-posted: https://stackoverflow.com/questions/44546232
The text was updated successfully, but these errors were encountered: