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

Closed
kwill opened this Issue Jun 14, 2017 · 7 comments

Comments

Projects
None yet
4 participants
@kwill

kwill commented Jun 14, 2017

My understanding is that:

  • OStatus is a decentralized social networking protocol made up of several other protocols (Atom feeds, Activity Streams, PubSubHubbub, Salmon, and WebFinger)
    • GNU Social and Mastodon are two server software applications that implement OStatus
  • pump.io API is an interface to the pump.io server software (Activity Streams, OAuth, Web Host Metadata)
    • identi.ca is a pump.io instance (not accessible right now), GNU MediaGoblin is a server application that currently uses a pump-like API
  • ActivityPub is a proposed decentralized social networking protocol
    • GNU MediaGoblin is a server application that will likely implement ActivityPub

How do these protocols interoperate? Does ActivityPub completely replace OStatus, or only the Activity Streams component?

Cross-posted: https://stackoverflow.com/questions/44546232

@kwill

This comment has been minimized.

kwill commented Jun 14, 2017

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?

@sandhawke

This comment has been minimized.

sandhawke commented Jun 14, 2017

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.

@strugee

This comment has been minimized.

strugee commented Jun 16, 2017

@kwill I'd also echo what @sandhawke said. To give some more concrete answers to your questions:

OStatus is a decentralized social networking protocol made up of several other protocols (Atom feeds, Activity Streams, PubSubHubbub, Salmon, and WebFinger)

Yes.

GNU Social and Mastodon are two server software applications that implement OStatus

Yes, and they interoperate because of that.

pump.io API is an interface to the pump.io server software (Activity Streams, OAuth, Web Host Metadata)

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.)

identi.ca is a pump.io instance (not accessible right now), GNU MediaGoblin is a server application that currently uses a pump-like API

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.

How do these protocols interoperate? Does ActivityPub completely replace OStatus, or only the Activity Streams component?

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.

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).

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.

@strugee

This comment has been minimized.

strugee commented Jun 16, 2017

Also, I'm not sure I understand what you mean when you say:

So interoperability would happen at the software layer, not the protocol layer

Can you clarify what you mean by "software layer" and "protocol layer"?

@sandhawke

This comment has been minimized.

sandhawke commented Jun 16, 2017

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.

@kwill

This comment has been minimized.

kwill commented Jun 17, 2017

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 kwill closed this Jun 17, 2017

@strugee

This comment has been minimized.

strugee commented Jun 19, 2017

@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.

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