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

Support ActivityPub #7422

Open
evanp opened this Issue Apr 11, 2017 · 17 comments

Comments

Projects
None yet
10 participants
@evanp

evanp commented Apr 11, 2017

Diaspora should support the ActivityPub ("AP") standard. AP provides a client-to-server API as well as a server-to-server federation protocol. It is the successor to the OStatus standard partially supported by Diaspora already.

Other social networking servers like pump.io and GNU MediaGoblin are moving to AP. There is some more information on the state of the ActivityPub network on the W3C wiki. We're trying to get everyone involved in federated social networking to rally around this standard and get a truly federated network working.


There is a $404 open bounty on this issue. Add to the bounty at Bountysource.

@DeadSuperHero

This comment has been minimized.

Member

DeadSuperHero commented Apr 11, 2017

Hi Evan, nice to see you here.

This is on our radar, and I think our system is modular enough to support a different federation protocol and schema, in theory. Unfortunately, adapting a new standard is a pretty slow process for us, and we're finally at a point that we are happy with our own federation protocol. However, I think many will agree that we eventually want to move towards greater compatibility with the rest of the federation.

One caveat is that we first need a dedicated person to work on it, which would involve creating a native Ruby implementation of ActivityPub that is compatible with Diaspora. The second is that we want to be certain that ActivityPub can support the privacy features that are leveraged by Aspects and private messages. As those are cornerstone features of our network, it's kind of an important prerequisite.

@evanp

This comment has been minimized.

evanp commented Apr 11, 2017

@DeadSuperHero Hi! I'm glad to be here. I think @cwebber can talk to the aspects and privacy issues. It's one of the big things we wanted to do with AP -- make it possible to share privately across servers.

@annando

This comment has been minimized.

annando commented Apr 11, 2017

There are some unanswered questions in the protocol like the question how to sign and distribute comments.

Diaspora distributes comments via the thread owner while pump.io (and AP?) Is distributing comments through the commenting account. This is an important difference.

@jaywink

This comment has been minimized.

Contributor

jaywink commented Apr 11, 2017

@annando actually, as far as I've been able to understand (read it a few times!), comments would be delivered by the thread owner. It would be impossible for the commenter to deliver them, that would be a technical impossibility, not sure how pump.io can do it?

When Activities are received in the inbox, the server needs to forward these to recipients that the origin was unable to deliver them to. To do this, the server MUST target and deliver to the values of to, bto, cc, bcc, and/or audience if and only if all of the following are true:

  • This is the first time the server has seen this Activity.
  • The values of to, bto, cc, bcc, and/or audience contain a Collection owned by the server.
  • The values of inReplyTo, object, target and/or tag are objects owned by the server. The server SHOULD recurse through these values to look for linked objects owned by the server, and SHOULD set a maximum limit for recursion (ie. the point at which the thread is so deep the recipients followers may not mind if they are no longer getting updates that don't directly involve the recipient). The server MUST only target the values of to, bto, cc, bcc, and/or audience on the original object being forwarded, and not pick up any new addressees whilst recursing through the linked objects (in case these addressees were purposefully amended by or via the client).

https://www.w3.org/TR/activitypub/#inbox-delivery

AFAICT that means exactly that the content owner is responsible for delivering any follow-ups - just like the Diaspora protocol requires.

@cwebber

This comment has been minimized.

cwebber commented Apr 11, 2017

Yup, servers of people higher up in the chain should deliver to their own collections of participants (read, Diaspora aspects or sets of followers) the content of comments they receive following the pattern described above. Indeed, that's exactly for the delivering to groups you don't have access to problem.

That's only for collections; if I add individuals or keep individuals cc'ed on the thread, my server can still deliver to them, and your server doesn't need to do the fancy forwarding behavior.

@cwebber

This comment has been minimized.

cwebber commented Apr 11, 2017

As for signatures, there's a signatures usage specification attached to ActivityPub, and this was partly added in response to feedback from Diaspora folks! (I wanted it, but the group thought it was out of scope until Diaspora based commenters declared that it was indeed needed.) It's not mandatory, mainly because the mechanism described has not yet fully matured as the de-facto way to do things at the time of the group, but the mechanism is there... and indeed, that's how I intend to do things (http signatures and linked data signatures).

One downside is that it hasn't been tested, though I did have a prominent member of the linked data signatures team review it before I added it. That's another reason it's non-normative... it needs implementation experience. If Diaspora folks are interested in working with me on implementing this forward, I'd be most eager to do it.

@annando

This comment has been minimized.

annando commented Apr 11, 2017

@cwebber Yeah, I was one of the people who gave feedback on this.

Concerning this comment distribution via a third party I'm very far from understanding the definition. This is partly caused by language problems (my English is okay for colloquial talks, but not for more), but also caused by my understanding problems of definitions of every kind. I cannot learn by reading definitions, but only by looking at examples.

Concerning AP and AS2, how would the following things be defined with them:

  • dislike (not removing of "likes", but disliking something)
  • events and participation messages for these events (attend, not attend, maybe attend)
  • forums (in OStatus they are called "groups")
  • private messages (in difference to posts to a limited amount of users)
@jaywink

This comment has been minimized.

Contributor

jaywink commented Apr 12, 2017

@annando

dislike (not removing of "likes", but disliking something)

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "summary": "Sally disliked a post",
  "type": "Dislike",
  "actor": "http://sally.example.org",
  "object": "http://example.org/posts/1"
}

Dislike is a core AS2 Activity.

Event is also a core AS2 Object:

{
   "@context": "https://www.w3.org/ns/activitystreams",
   "type": "Event",
   "name": "Going-Away Party for Jim",
   "startTime": "2014-12-31T23:00:00-08:00",
   "endTime": "2015-01-01T06:00:00-08:00"
}

There is also a Group Actor type. Don't ask me how to use it though ;)

@annando

This comment has been minimized.

annando commented Apr 12, 2017

I'm definitely lost in these specifications. So there is some "like" and "dislike" in AS2, additionally "Like Activity" and "Like Collections" ... On Diaspora a "like" (or "dislike") is simply this: https://diaspora.github.io/diaspora_federation/entities/like.html - and it is transported like every other message, that's all.

To do anything with AS2 and AP (in Friendica) I will need some "translator" and some existing implementation, that's for sure.

@cwebber

This comment has been minimized.

cwebber commented Apr 14, 2017

@annando I'm not sure how it's more complicated... the Diaspora description and the ActivityStreams definition look not too far off from each other. But if you need help, give me a ping.

@annando

This comment has been minimized.

annando commented Apr 15, 2017

As an example: How do I repeat a post? In the current Diaspora protocol it is described here: https://diaspora.github.io/diaspora_federation/entities/reshare.html

In the AS2 description (and the vocabulary) I haven't found clue to do this.

I guess that I have to contact you very often :-)

@cwebber

This comment has been minimized.

cwebber commented Apr 18, 2017

Well you're welcome to contact me... as co-editor of ActivityPub, I even encourage it. :)

You're right that the (re)share bit was missing... that was caught a few days ago, and we're talking about it tomorrow on the call. That's the whole reason the spec is going through several cycles before it hits a recommendation! Specs are written by humans, and humans fail... I probably fail more than most, even. But we're seeking feedback.

And indeed, AP has already been shaped by the contributions of both of you (@annando and @jaywink). We're now at the point in the spec where we're relying on people actually implementing things, and catching what's missed or needs to be adjusted based on that feedback. I do want, and appreciate, your feedback, both from reading and from implementation experience if you're willing to give it.

So if you see things that are missing, or that need clarification, or have errors... yes! Please do contact me! Or file an issue! This is the time to do it!

@cwebber

This comment has been minimized.

cwebber commented Apr 18, 2017

BTW, I wrote up a little ActivityPub tutorial which might even get put at the top of the AP spec (obviously with the ascii art becoming real graphics) in case that's of help to anyone here.

@hex-m

This comment has been minimized.

hex-m commented Oct 5, 2017

Is this issue just about the server-2-server part of AP (federation) or does this relate to #7422?

@Flaburgan

This comment has been minimized.

Member

Flaburgan commented Oct 5, 2017

#7422 is this issue, which one are you talking about? But yes, this is about s2s, not c2s.

@hex-m

This comment has been minimized.

hex-m commented Oct 5, 2017

Thanks for the clarification. And sorry - I meant #3467.

@jhass jhass added the bounty label Apr 15, 2018

@roipoussiere

This comment has been minimized.

roipoussiere commented May 7, 2018

Related discussion on Discourse: Let’s talk about ActivityPub.

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