That’s the problem. Or not, depending on some implementer’s desire to federate reliably with Mastodon and similar microblogging platforms. It’s spec-compliant AFAICT. The spec allows an Announce of anything, People, Places, Events, even other Announce activities. However, no implementation I know of completely supports the full flexibility of the specification and that’s fine. Again, this is only an issue if interop is a goal.
In the interest of keeping this on-topic, I’ll refrain from litigating this chain of replies and instead summarize my points of contention, so as to be clear:
- The “goal” of ActivityStreams is to describe objects and collections, with an emphasis on social objects and activity streams.
- The “goal” of ActivityPub is to define standardized side effects for activities, as well as provide a common interface for actors to communicate via inbox/outbox according to these side effects.
Put simply, a collection of activities is an “outbox”. You may separately have a collection of objects representing a thread, intended to be fetched as a generic linked data representation – this is where you would serve your object, replies, context, and so on, without requiring them to be wrapped in activities.
The core proposed behavior is as follows:
- A “thread” or “topic” can be represented by a Collection of posts. This Collection can be referenced via
context. It can be fetched directly. The posts areattributedTowhoever wrote them. The collection isattributedTowhoever is managing the thread. - A “thread” or “topic” can also be represented by an actor. This actor distributes activities related to the “thread” or “topic”, like how a mailing list works. You can Follow it. You can send it an activity and it will relay that action accordingly, e.g. via FEB-1b12, via inbox forwarding and/or Add activities, via a “boost bot”… however you wish.
Additional behavior can be implemented as follows:
- A category actor can Create/Announce/Add/etc any topic actors, if you wish to replicate this information via ActivityPub federation. Your followers will have to understand such activities targeting a “thread” or “topic”, however that may be represented. Adding a topic to the category seems natural to me, but I believe FEP-1b12 expects you to Announce a Page object.
- Following the category actor alerts you to new topics in that category.
- Following the topic actor alerts you to new posts in that topic.
- Following the user actor alerts you to new posts by that user in any topic.
This should broadly support all kinds of implementations, including ones that make different decisions. Say you want to be able to split a topic. It seems natural to me under an Add/Remove system, your Client could Remove the posts from the old topic and Add them to the new topic. Under current systems, you wouldn’t have any mechanism for this, as long as there is no explicit representation of a “topic” as separate from the reply-tree.
Aside from this, I will weigh in on at least one other thing: Mastodon triggering the ProcessCollectionService as a result of activities arriving in the outbox is a quirk of Mastodon, not something natively supported by ActivityPub. Even in Mastodon’s case, it mostly expects a Collection of Notes, such as a pinned posts collection being fetched via featured on the profile. Spec-wise, it’s ambiguous because there is no expectation to have multiple object in an activity, so the behavior for such cases is not clearly defined. You could maybe expect being able to map the action to all objects in a functional way, but implementations would have to support this explicitly, and I think most if not all current implementations expect only a single object. There would also probably be issues with doing multiple objects as well – what happens if you Add 10 objects to a collection, but only 7 of those succeed, and 3 of them fail? Was the activity overall a success or a failure? Do the failed objects get retried? These kinds of questions should be answered before attempting such a distribution.
3 Likes
Oh I think I get it now. You want to send a collection of activities to inboxes of other instances instead of sending them one by one, is that right? I dont think its a good idea, because Im not aware of any platform which would support this. Besides it sounds like premature optimization, Lemmy sends countless activities (including for each individual vote) and it works without problems, the main server load is from local users not federation. Whats the purpose of the 5 minute publishing delay anyway?
I’m on board with this and the Discourse plugin is doing it already.
I don’t really have an issue with this. I’m not sure if it’s supported anywhere, but I guess you have to start somewhere. Can you give me a very specific, very simple example to work from (please not a big wall of text 
).
I’ll address this in the context of your next point.
I agree with this new phrasing, i.e. can also (the emphasis is mine). To use an analogy you can “Watch” a topic in standard Discourse (bell next to the timeline on the right) and you’ll get notifications about that topic. However that’s just one way of discovering content. I don’t think it makes sense to give the topic Actor primacy in the way you were suggesting before. The Discourse plugin may add topic actors at some point to support this behaviour (indeed it’s already arisen as a possibility in internal discussions).
Yes, I agree with most of this. I would phrase some of it slightly differently, but yes, it follows from the above. The main thing I would say is I don’t see the need to make this the only way threaded content in ActivityPub works. We’ll add support for your desired use of context for topic collections and perhaps add topic actors, but not to the exclusion of the other methods of discovery of content.
- @nutomic Mastodon supports it. @trwnh I appreciate what you’re saying about the provenance of this however the fact is that this is what Mastodon actually does, i.e. it processes collections, and you have to take things as you find them to an extent. If you send an OrderedCollection of Activities to the Mastodon inbox it will process it in order. However that functionality came to be, whatever its original purpose, that’s what it does currently.
- @nutomic The purpose is essentially to give the OP breathing space before they publish to the fediverse (i.e. time to delete, edit etc). This was also requested from a few different interested folks (see the plugin’s topic on meta.discourse.org).
- @nutomic @trwnh Thank you for your thoughts on this as I can see we’ll need to change the default behaviour here for wider support.
That said, I don’t really see why processing a Collection of Activities shouldn’t be more widely “supported” (caveat @trwnh’s point) than just Mastodon. A Collection is just another Object. And in some scenarios it seems to be more efficient to send a Collection in one POST. Indeed there seems to be some overlap between this way of thinking about a topic/thread and @trwnh’s preferred approach. But I’m not going to die on this hill. It’s relatively straightforward for the Discourse plugin to just send individual Activities to inboxes instead.
1 Like
Mike Macgirvin responded with:
There are good reasons why not everybody is willing to adopt the Lemmy solution. And that is Private Groups and comment permissions. I’ve been telling people this for a long time and probably sound like a broken record, but when one does private groups, and especially when one adds comment permissions to that situation – everything changes. Really, everything. So start with that, or one finds they have painted themself into a corner - as nearly every project supporting groups is currently doing.
Mike isn’t on this forum so it’d be great if any Group devs on here could engage with him via the linked fedi thread.
1 Like
FEP-1b12, “The Announce activity” section:
In case the incoming activity is deemed valid, the group MUST wrap it in an
Announceactivity, with the original activity as object. The wrapped activity MUST be preserved exactly as it was received, without changing or removing any properties. This ensures that forwarded activities can be verified with [Object Integrity Proofs].
How recipients of the Announce activity should verify the authenticity of the wrapped activity?
If wrapped activity contains an integrity proof, we can verify the proof and see that it was created by the actor. But, as far as I know, existing FEP-1b12 implementations don’t use integrity proofs. Do they re-fetch all wrapped activities from the server of origin?
This information seems to be missing from the FEP.
Lemmy doesnt do any such verification, because we already trust the community by following it. Even with authentication, a malicious community could do numerous bad things like banning innocent users or not announcing certain activities. So authentication would only solve part of the problem. And in practice, users would notice such manipulation themselves and migrate elsewhere.
This is quite different from the microblogging world, where any user can make a controversial post which gets shared across the whole network. So verification is more important there.
The thing I’m worrying about is impersonation. A malicious community could announce an authentically looking post attributed to, for example, a Lemmy developer, which directs people to some phishing page. It is hard to tell in advance if community can be trusted or not.
I’d argue that this is more serious than banning / censoring.