Creation of remotely managed objects


#1

When you Create a Note , your server hosts it for you. But some objects need to be hosted by one of the recipients, not by you. You can of course host your copy, but, the interesting copy will be elsewhere. How should we express that using ActivityPub?

It’s possible to use Create , but the problem is that it would add new side effects / semantics to an existing established activity with established semantics. I suggest the following, and it’s also basically what Vervis is currently doing (for creating new tickets across servers):

  • Use the Offer activity for this.
  • If you want to host a local copy of the object, first Create it and then link to it in the Offer .
  • If you don’t care about a local copy, embed the object in the Offer . You’ll be hosting the activity either way, and the object will be available inside it.

Thoughts/ideas/objections? :slight_smile:


#3

The usage of Offer as described sounds just as much a semantic misstep as Create if not more.

What we came up with at Allied was something we call SOAPYAPE. (Simple Originating Author Publish Yonder Activity Pub Extension/endpoint)

There are a few different scenarios it covers, I’m not sure if yours are included. There isn’t really a home for the spec yet since we haven’t used it on the public fediverse yet. I’ll try to summarize…

An actor supporting this extension publishes a url in the endpoints list on their actor object under the key soapyape. When a user wants to create an object on the foreign site, the site prepares the object then sends it to the endpoint in an oauth-like flow. On the user’s home server an activity is generated with a result of the Create activityid staged on the foreign server. This new homeserver activityid is then passed back with nonce and signature to the callback url and a origin property is added pointing back to the corresponding Create on the user’s homeserver. The object is then sent out.

Both Creates should point to each other and in this way receivers can authenticate different-origin authorship.

The main usecase this was created for was for application servers that generate interesting objects that identity servers don’t understand or know how to create. The identity server still gets to keep a copy this way as well, and can one day learn how to read/edit it with software update.

If the identity server does know how to create the object, C2S API with one of the regular oauth endpoints might be more appropriate.


#4

I’d rather not “create” remote objects with AP.

My current understanding of S2S AP is that it basically is just moving around "$ACTOR [did] $ACTIVITY ([on/with/…] $OBJECT)" messages.
For example "https://criztovyl.space/actor Created a Note". The Note Object then contains subject, content, etc. Not sure about the receipients(?) rn, but I think they would go to the Create Activity.

For issues I then would rather go "https://myforge.net/myuser FoundIssue Issue" The FoundIssue Activity contains the repository the issue was found in (dereferenceable ID), the Issue Object further describes the issue. The Issue Object would be transitive (no ID) and would trigger the creation of an real Issue Object in the corresponding repository as an side-effect, as soon as the Activity reaches the corresponding server.

I think that might be an more AP-y way to deal with this challenge.

But that’s just my thoughts.


#5

See this post:

TL;DR: do C2S ActivityPub. It’s explicitly meant to do “remote creation” of objects.


#6

@rialtate, your method sounds very custom and complicated, to use for something that is quite fundamental in my use case: Offering objects to other servers. Could you explain why you’d prefer it over simply using an Offer activity? (and keeping Create clean and used as “publish a thing on my homeserver”)

@criztovyl, issues/tickets aren’t found, they’re just opened/created :slight_smile: I agree problems are found, but, not all tickets are problems. Some of them are just ideas, thoughts, proposals. So you’d generally “offer” a ticket to some project’s ticket tracker. And the ticket would get accepted or rejected, either manually or automatically.

@_cj, hmm that topic is full of general ideas, what’s the bottom line that you’re suggesting? :slight_smile:


#7

@fr33domlover as I said the main use case is for when the author’s software doesn’t know how to make the object, it can’t Offer something that it doesn’t even know how to Create. If it does, then C2S API is more direct. @_cj also mentioned this.

Edit: “more direct” vs. an Offer. C2S is in fact the inverse of SOAPYAPE, and to have a complete UX you would need to support both. One initiates locally (C2S) and the other initiates at the destination site.


#8

@rialtate, ah I understand now. Thanks for the clarification.