Publishing Archives without Delivery

[mediaformat]

"As an ActivityPub API client developer, I would like to offer users the opportunity to import and publish their archived content, without enqueueing the content for federated delivery."

The imported posts could optionally be added to some custom collection, but important part is to prevent delivery and overwhelming followers timelines.

[trwnh]

i guess you could Add to outbox? if the outbox recognizes this as a self-import, it can insert every as:object into the set. the Add would not be addressed to anyone.

in a more general sense, with an archive format for the outbox, this problem kind of goes away because you can just copy files around outside of activitypub (using http put, or ftp, or sftp, or any other program/protocol for file transfer...). if the links are relative, you don't even have to rewrite anything except the base url. however, AS2-Core currently recommends against using relative links.

[mediaformat]

Another thing to consider, for server software supporting an archive import, might be signalling to the client batch sizes.

The thinking behind this is not only importing from other AP software, but importing from other siloed software, where users may have ~20 years of posts. Making a selection of which posts to import from the archive is likely a client concern, however servers may want to limit how many posts should be treated per "transaction".

[trwnh]

if the posts aren't activities or convertible to activities, then wpuldn't they be out of scope of activitypub? the concern at that point becomes "how to host http resources" and tangentially "how to let others discover those http resources". traditionally this is done using a sitemap or index.

an AP outbox is canonically a sort of feed, descended from Atom and AtomPub (which was extended with activitystrea.ms 1.0, which gained a json serialization in as1-json, which was reworked into activity streams 2.0, which gained a publishing protocol with activitypub). you can go further back to rss and related syndication efforts that allowed channels/items to be published on other sites (and where atom uses feeds/entries, and activitypub uses outboxes/activities...)

...so as long as activitypub uses activities and outboxes, the question is more "how to syndicate outboxes" and "how to add activities to new outboxes". with http POST being a way to create new activities and maybe process side effects.

[mediaformat]

I'm thinking specifically of pre-dated Activities, which may be fetchable via the inbox. But which a user may decide to only deliver via Announce at a relevant time.

[mediaformat]

Clearly, the Activities must not be posted to the outbox if they are NOT meant to e delivered (federated).

Federated servers MUST perform delivery on all Activities posted to the outbox according to outbox delivery.

This is probably a case for creating a Collection and adding Activities to that collection

[trwnh]

you should be able to post to outbox without delivery, but this is not really defined.

MUST perform delivery

this was errata'd to SHOULD i think, by cg resolution, although that creates other issues: w3c/activitypub#482

the missing abstraction here is probably the idea of publishing activities without delivering them, but even in the case where outbox delivers, the proposal described above will Add to outbox without addressing anyone:

type: Add
object: activity1, activity2, ..., activity1000
target: outbox
# note the lack of addressing

where to POST this activity is an open question, though.