Skip to content
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

Clarity on behaviour with multiple Announce activities for the same object #386

Closed
evanp opened this issue Sep 6, 2023 · 5 comments
Closed
Labels
pending-closure-in-7-days This issue will be closed in 7 days after review

Comments

@evanp
Copy link
Collaborator

evanp commented Sep 6, 2023

The Announce activity type is typically used for "share", "retweet", "boost" or "repost" functionality on the social web.

In many social systems, it's reasonable to repost the same object multiple times (for example, a reminder of an upcoming event). Because Mastodon doesn't allow multiple Announce activities, although they're not forbidden in the ActivityPub spec, we need some extra guidance on what to do with repeated Announce activities.

@evanp
Copy link
Collaborator Author

evanp commented Sep 6, 2023

Quoting @trwnh from #384:

Although I have to raise another point of contention: when was it decided that Announce should be idempotent with respect to shares? This is starting to feel like implementation decisions are being raised into the spec itself. For example, if Tumblr decides to implement reblogs as Announce then they will want to support multiple shares most likely. And the original intent with #381 was to clarify cases where a "like" is a kind of post, not a binary signal. This is also why I brought up in #381 that there should be more clarity on the split between a "resource" and a "procedure".

#384 (comment)

@evanp
Copy link
Collaborator Author

evanp commented Nov 22, 2023

I wrote a Primer page on Announce:

https://www.w3.org/wiki/ActivityPub/Primer/Announce_activity

I focused on the interoperability between implementations that expect idempotent shares (one share per object per actor), versus those that allow multiple shares per object per actor.

@evanp evanp added the pending-closure-in-7-days This issue will be closed in 7 days after review label Nov 22, 2023
@nightpool
Copy link
Collaborator

nightpool commented Nov 22, 2023 via email

@nightpool
Copy link
Collaborator

nightpool commented Nov 22, 2023 via email

@evanp
Copy link
Collaborator Author

evanp commented Aug 2, 2024

I'm satisfied with this process, and I think we can follow up in the Primer if we need further discussion.

@evanp evanp closed this as completed Aug 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pending-closure-in-7-days This issue will be closed in 7 days after review
Projects
None yet
Development

No branches or pull requests

2 participants