Who generates the Push activity?

This post continues the discussion about how to implement repo push activities. My current implementation does the following:

  • You run git push or darcs push
  • The server authors a Push activity and publishes it, with you as the actor
  • The repo itself isn’t one of the recipients yet, but in my docs I decided it should be, I’ll fix that soon :slight_smile:

This works fine so far, assuming you like the idea that the Push activity is authored on the server while you’re the actor of the activity and not the repo. But there’s a complication: What happens when you push to a repo hosted on a different server, not the one where your account is? In that case, the server can’t publish the Push activity for you!

So I’d like to ask the following:

  • Where is the Push activity authored? On the computer of the person? On the person’s home instance? On the repo’s home instance?
  • Who is the activity’s actor? The person or the repo? (the spec says the AP actor is the entity that did the activity, so in that sense it should be the person, not the repo, and that’s how I’ve implemented it so far)

The answer also needs to make sure that those Push activities are authentic and honest and match the actual repo commits, otherwise anyone can claim pushing some fake arbitrary commit to any arbitrary repo.

Idea, maybe instead of a Push activity we could have a Receive activity in which the repo is the actor?

I’d go with the Receive Activity.

Can you explain why? :slight_smile:

Activities are generally in active phrasing, an actor states what they do. So a Receive activity or BePushedTo or whatever we call it, would be very strange. If we use it, we should be sure it’s the best thing despite that weirdness.

There are many other options, such as having repos attach signatures to Push activities, as proof that the repo approves their content.

Hmm, from repository view an "$x added $commits to $repo" activity is inherently passive, I think. And Receive is passive, that’s why I chose that.

But you are right about the active phrasing.

One could make it active by turning it into an "I, $repo, accepted $user's push containing $commits" activity, like the Accept activity. But as the SCM transfer is not via AP, an AP Accept might be confusing without an preceding AP Offer.

Maybe AcceptPush then? :slight_smile:

In a way, yes, a push is a kind of Offer. And an Accept would make sense.
But if we have only the Accept, whose object is an anonymous Push
attributed to the person, repos can claim attribute fake arbitrary commits
to arbitrary actors. This is already possible in forges, unless gpg
signatures are attached to the commits.

So, yeah, one way is this weird BePushed activity, which would be published
by repos and allow people to follow repos and trust web UIs to be honest
about what got pushed and by whom.

Is this enough?

In Git there is a pre-push hook, which may allow the Push activity to be
reliably generated by the client. Even if not, there are tricks we could
use, to have the Push published by the person. But then, how do we get the
repo to verify that the Push matches what it received through git?

Idea: What if, just for this one case, we define an exact strict mapping
between VCS pushes and their ActivityPub representations, and then the two
sides can verify correctness? Or at least verify just the commit hashes.
The upside of this is that all pushes will be http-signed both by the
person and the repo.

Maybe how-far-to-go-with-this should depend on the requirements: For what
do we need Push activities? I suppose we need to:

  • See pushes in people’s activity history?
  • See pushes in repo activity history

Assuming that, we do need both parties to approve the push. Either the
person publishes a Push and the repo approves it e.g. via an Accept, or
repo publishes a BePushed and person approves, e.g. via an Announce or a
Push referring to the BePushed.

Very relevant post: Representing digital events external to ActivityPub