Very useful! Thanks for doing that. This generally chimes with my current understanding of the role of the audience property. It is making me think we may need an "Addressing" FEP to describe how to use audience AND to/bto/cc/bcc . I'm curious to get others' takes on what we've already laid out, and what you've just dug up.
cc @devnull @pfefferle @nutomic @eprodrom
Posts
-
Topics in the #threadiverse -
Topics in the #threadiversetrwnh: I recall in conversation around the time that 1b12 was first being written that the use of audience was motivated by not wanting to iterate through to/cc to find a Group actor. so the point very much seems to be to indicate the Lemmy community that you posted the activity to, but not using to. (i don’t particularly agree with this usage, but that’s how it was presented.) ... well, audience has nothing to do with “belongs to”, really. Activity Vocabulary indicates that activities can be “scoped to a particular audience using the audience property” – the definition of which is “one or more entities that represent the total population of entities for which the object can considered to be relevant”, as given in Activity Vocabulary specifically. now, that’s a poorly-worded definition (grammatically speaking), but “can [be] considered to be relevant” is the operative part of it. in activitypub, due to the way that audience works for delivery, it makes for a useful mechanism for “keep these people in the loop” if you copy the audience over to your own activity. and if audience is a collection, you can make use of inbox forwarding to especially keep bto and bcc recipients in the loop. ... the problem with that is that 1b12 is already FINAL status and can’t be updated. with that said, i am wondering if the use of audience deserves its own FEP or whether it’s enough to be “part of” other FEPs like 1b12 and 7888. I would firstly direct you to the text of 1b12, which is the primary thing we're talking about here. Audience property In order to render content in a forum, it is necessary to know which particular forum the content belongs to. Emphasis is mine. But this is really by-the-by, the question is what we do now. 1b12 is not a bible. It is a good description of the approach we've decided to take to deal with group federation, but it was never going to be the last word on the subject, particularly as it was written prior to platforms like Discourse, NodeBB, Wordpress etc starting to federate in this way. trwnh: i am wondering if the use of audience deserves its own FEP Perhaps. My thinking is we should flesh out the thinking here a bit more and see if we can land in a place that warrants clear definition. I think the goal here is an approach that works for these various platforms that make significant use of multiple, and overlapping, audiences. trwnh: in general you wouldn’t want to [have an array in the audience], however. it’s easier to have a collection representing the sum total audience, rather than just relying on a JSON-LD set/array. hm, right now, I'm not sure I agree. I think it is better to represent reality as it is. In the case of overlapping taxonomies from a normative perspective the "audience" is not a single collection. It is inherently pluralistic. Moreover the audience property can equally be an array of collections. Right now I don't see the utility of artificially forcing it into a single collection. The other thing to keep in mind here is that we're not really contending with widespread existing usage here. As 1b12 also observes Currently there are different approaches to specify which group a given object or activity belongs to ... To simplify this process, we propose to specify the group identifier in the audience property In other words, there isn't a widespread existing convention with respect to the audience property. We need not be constrained by those kind of considerations here, as we sometimes are in other respects. We can operate from first principles here more than we sometimes do. -
Topics in the #threadiversetrwnh: this sounds like it won’t work nicely with 1b12 as 1b12 seems to assume a single Group actor in audience. so putting multiple values in there might not violate the letter of the FEP, but it seemingly violates the spirit of it Hm, just an initial take, but not sure I agree. Again, this is preliminary, but I’ll start by listing a few things I think suggest having multiple actors in the audience properly may make some sense, and be in the spirit of 1b12: Firstly, from a purposive perspective 1b12 “reintroduces” the audience properly as it were, noting that it is underused and could suit this type of federation (i.e a group federating content on behalf of other actors). In that spirit I feel it would be a bit over-determined to limit the ways in which the property could be used in this vein. To put it another way, I don’t think @nutomic was attempting to enumerate all the possible ways this style of federation could work, rather he was attempting to describe a way it can work, based on the way it does work in some existing implementations. I think there is scope for multiple audiences in that spirit. Secondly, from a normative perspective, I think it’s useful to think about the ways in which the activity of an actor “belongs to” a, or multiple, Group actors in the sense discussed in 1b12 and in the sense implied by the audience property itself. In the case of overlapping taxonomies, e.g categories and tags in Discourse or Wordpress, it doesn't really make sense to say that the activity of an actor with multiple taxonomies “belongs to” any one of those taxonomies. It belongs to each of them equally. To force it to belong to one of those taxonomies as the “primary” feels a bit artificial in the context of a platform like Discourse (or Wordpress for that matter). Thirdly, given that 1b12 is itself relatively “new” (in a standards sense) I feel that there is still scope to “flesh out” the way the audience property can work in this approach, particularly as we start to apply 1b12 to new cases like those of NodeBB, Discourse and Wordpress. Lastly, I should clarify that part of why I think listing multiple follower lists in the audience may make some sense is because the audience affects inbox forwarding. If other platforms are to forward the activity correctly they should know what its full audience is. In the case of multiple taxonomies that audience includes the followers of each taxonomy. -
Topics in the #threadiverseIn cases of taxonomic overlap this is what I think should happen, and what (should) currently happen in the Discourse plugin (bear in mind this is a very new problem for the Discourse plugin too): Actors following multiple taxonomies associated with the post get a single activity. Actors following one taxonomy associated with the post get a single activity. The "collection" referenced in the Object context will be the Topic the post is in (it's only in one, even if there are multiple taxonomies). The "audience" of both the announce and the activity it's wrapping should include all relevant audiences the activity was published to, i.e. the followers of the various associated taxonomies (it can be a list). Now that I say this, I'm not sure the Discourse plugin is doing 4 properly yet, but that seems to me to be the right approach. Curious on others' thoughts. *edit, yeah 4 is not currently the case in the Discourse plugin. We just select the first taxonomic actor from the list of applicable taxonomic actors (preferencing tags over categories), but I don't think that's the "right" approach. Curious on others' thoughts on 4. -
Topics in the #threadiverse@pfefferle Glad to hear you're thinking of adding category and tag actors. That will work with Discourse, NodeBB and Lemmy, as long as you follow FEP-1b12 (which is what we've followed to support "taxonomy" actors) https://socialhub.activitypub.rocks/t/fep-1b12-group-federation/2724 julian: I believe Angus is planning on exposing tags as actors. We actually now do! The PR was merged 4 days ago: https://github.com/discourse/discourse-activity-pub/pull/84 julian: what happens to a tag that is named the same as a user? In Discourse you select the ActivityPub username of the Actor while creating it and there's a uniqueness check at that point, so in the case of such a conflict you'd have to make the new Actor's name slightly different. pfefferle: But it seems technically possible to use prefixes like ! or ~… ActivityPub and WebFinger The only thing that really matters is that the ActivityPub username of the actor is unique on a domain, allowing Webfinger to work properly. A prefix is just one way to achieve that. You could do what the Discourse plugin does, i.e. ensuring preferredUsername uniqueness at the time of Actor creation. I am assuming separation of concerns here. In the Discourse plugin ActivityPub usernames are, in some circumstances, initially populated from Discourse usernames (or category or tag names), but in all other respects are independent from them. -
Traversing the reply chain when working with topicsYeah, I agree with you on both points. It’s similarly inexpensive to make 20 requests in Discourse (it’s in a background process on a seperate thread). On reflection I think part of my conservatism here is that I don’t like that Mastodon doesn’t forward activities properly and I don’t like starting from a position that I need to import 20 notes that Mastodon failed to forward to me It causes similar metadata issues in Discourse. -
Traversing the reply chain when working with topicsI guess one of the things I'm assuming is that other services are implementing the Inbox Forwarding spec correctly, which would mean that, in an ideal world, you should already have the replies you should have anyway and this is more of a "stop gap". https://www.w3.org/TR/activitypub/#inbox-forwarding However, I note that Mastodon violates the spec here, which means that more replies from Mastodon might be missed than is ideal https://github.com/mastodon/mastodon/issues/5631#issuecomment-343039649 -
Traversing the reply chain when working with topicsThe honest answer is that a limit makes some intuitive sense to me, but I have medium to low confidence in the cogency of my thinking on both the limit and where it's set. I've set it at 3 as that seems to be the more "conservative" (read "safer") approach while I think it through further / see how this first version works in practice. In terms of the "risks" (to the extent they exist) I think I'm thinking a version of the following: You could be sent a random Note inReplyTo an unrelated Note that's part of a large chain which you end up traversing for no reason. Even if you eventually get to a Note in an existing topic, say 20 replies in, is it still right to say that those replies are part of your topic in a coherent sense? In what scenario would you be missing 20 odd replies? Perhaps there is one. -
Traversing the reply chain when working with topicsThe Discourse plugin will implement reply chain traversal for the purpose of topic detection when this is merged: https://github.com/discourse/discourse-activity-pub/pull/98 Essentially it implements the following (but with a limit of 3 instead of 5. angus: Go back N number of replies (perhaps 5) to see if there is a Note already associated with an existing post. If we find a Note (say at the 4th iteration) we import ALL of the intervening Notes, and add ALL notes as new posts in the relevant topic. So we’d end up with 5 new posts in the existing topic in this example. If you're curious about the detail see the ContextResolver spec: spec/lib/discourse_activity_pub/context_resolver_spec.rb -
Traversing the reply chain when working with topicsYeah, I didn't mean to suggest the inReplyTo object wasn't available. Just that if it's not already present locally, or it doesn't have a context, the plugin is currently creating a new topic with that Note. Hence the need to traverse the reply chain to determine if there's an existing topic to put it in. I guess the point is here that reply chain traversing in a forum is more specifically for the point of topic detection and curation (making sure the right Notes end up in the right Topics). A post cannot exist outside of the context of a topic like it can on social media. -
Traversing the reply chain when working with topicsI've just been cleaning up [email protected] as it had a number of orphaned replies that had been turned into topics. The immediate fix for this is to discard a Note if I don't have the Note it's in reply to (instead of creating a new topic) (PR for that is here), however I know that some implementations try to "walk up" reply chain. I guess I'm thinking out loud here as to how much reply chain walking makes sense in a forum context. I mean ideally we have a collection in a context property to work with, and the Discourse plugin actually checks this already, but we don't live an ideal world. This is what I'm currently thinking for reply chain walking: Go back N number of replies (perhaps 5) to see if there is a Note already associated with an existing post. If we find a Note (say at the 4th iteration) we import ALL of the intervening Notes, and add ALL notes as new posts in the relevant topic. So we'd end up with 5 new posts in the existing topic in this example. Curious what others think on this. -
This is a test-federationWhat happens if I reply? -
May Meeting: May 2 1700 UTCUpdate! The meeting will now be at 1700 UTC on May 2. This works slightly better to allow more folks to come. The Discourse plugin just sent out an Update activity with the new time, but just in case anyone misses it, here's another Note (i'll ping the mailing list too). -
May Meeting: May 2 1700 UTCOur May meeting will be on Thursday, May 2 from 1700 to 1800 UTC. Check out the Agenda prep here https://socialhub.activitypub.rocks/t/agenda-prep-for-may-wg-meeting/4117 Here's the video-call link we'll use (we're going to give Jitsi a try). https://meet.jit.si/moderated/9c481833cd57ccddab05ac977217ca5db63a209fbfee3f82b1627d4e0548190b All are welcome! -
Publishing / Processing Collections of ActivitiesOk, the Discourse plugin will always publish activities, one at a time, even if publication is delayed, once this is merged https://github.com/discourse/discourse-activity-pub/pull/89 -
Publishing / Processing Collections of ActivitiesAnother practical issue @devnull and I faced when integrating NodeBB and Discourse is that the Discourse plugin has been publishing collections of activities to its followers if "Full topic" is enabled (i.e. all posts in a topic will be federated). I built the plugin this way to accommodate an initial publication delay after the first post is made in a topic. Other posts may be made during that delay period, so the thinking being that rather than send multiple POST requests to the followers of that actor at the time of publication, you would just send them a collection of activities. In other words Topic is created. A few posts are made. Publication delay period ends. Publish the topic's full Collection of Activities to followers. As Mastodon also supports processing a collection of activities this seemed to make some sense to me. However, as I think @trwnh warned me, this has not turned out to be popular. There might still be something in this approach, but I'm going to be moving to just publishing sequential activities, even if there are multiple to publish at one time. That said, I think there may be normative support for representing a topic (/thread) as a Collection, so the processing of Collections may become more of a practice in time. -
How do we handle Groups (Reconciling FEP-400e and FEP-1b12)?@trwnh Thanks, this is very helpful. I agree with pretty much everything you've said. So from a practical perspective, for the purposes of implementation, this topic (i.e. reconciling FEP-400e and FEP-1b12) essentially boils down to trwnh: The one point of intersection is whether any given actor will send out an Add or an Announce I think it would be helpful to work through an example of where this particular point of intersection may become an issue. trwnh: Consider the common forum use-case of “splitting a thread”, which involves moving a post to another thread. That post may be a reply to a post from the original thread. It’s important to be able to specify the intended grouping as a separate thing from who you’re responding to. So, this would result in something like: You receive Note 2 (with context A, a collection) which is inReplyTo Note 1 (with context A) You receive an Update to Note 2 and it now has context B (a collection)? OR perhaps you receive an Add of Note 2 to context B? In both 2 and 3, the inReplyTo would still be to Note 1, which would still have context A. @trwnh something like that? -
How do we handle Groups (Reconciling FEP-400e and FEP-1b12)?silverpill: Regarding FEPs: they do not describe how things are handled in practice. FEPs are proposals, and can be about anything, as long as it is related to Fediverse. I think what @nutomic meant was that FEP-1b12 attempts to summarise the most widely used approach to federation by Group actors, which I think it does. Nevertheless, as an implementor you're still faced with some questions like @silverpill's (i.e. about private groups), or how to deal with Mastodon's pending implementation, or how to think about this with respect to FEP-400e and FEP-7888. Navigating that thicket in a consistent way across the various implementations in #meeting:threadiverse-wg is the goal here. We definitely don't want to create another standard (que xkcd comic about a standard to standardise the existing standards). -
How do we handle Groups (Reconciling FEP-400e and FEP-1b12)?This is a topic to track the FEP-400e and FEP-1b12 reconciliation, aka "How do we handle Groups". I've made this a wiki to let implementers describe their current status quo https://codeberg.org/fediverse/fep/src/branch/main/fep/1b12/fep-1b12.md https://codeberg.org/fediverse/fep/src/branch/main/fep/400e/fep-400e.mdDiscourse
Currently Discourse implements FEP-1b12 to federate posts associated with Category and Tags, i.e. Activities are Announced by a Category or Tag actor.NodeBB
NodeBB implements FEP-1b12 to federate posts associated with a category (tag actors TBD).Lemmy
Lemmy implements FEP-1b12[Add your implementation in here]
-
How do we handle Groups (Reconciling FEP-400e and FEP-1b12)?Absolutely! We're not trying to create a different implementation. We all have adopted FEP-1b12 already The goal is to understand how that works with the other standards which handle different, but related, concepts.