Hello everyone!

Julian and I are both thinking that it probably doesn't make sense to hold an in-person meeting in July, as the agenda is effectively the same as our one in June, and right now there is just some work that needs doing (particularly by me!). A call would not be time well spent right now.

The work of our group continues here in our federated categories and we're looking forward to seeing everyone in August

@codenamedmitri Is it possible to make a note on our calendar entry about this? Thanks

I think the answer to that has to be that you have to take whatever context is associated with the object you're sent as canonical. Otherwise we'll always be second-guessing. The context on the object of the first object in whatever collection you resolve could also be "wrong". Yes, practically speaking, this may lead to errors in certain cases, however I think that's better than making the context overly relative.

**edit I guess in this case, practically speaking, you'd follow up with the implementer of whatever platform is being used to resolve the context you initially got and ask them to fix their issue

@jupiter_rowland I'm curious if you actually posted twice or if your post appearing twice is a bug in one of our implementations.

julian:

We can do this, we can send richer HTML across the protocol in such a way that all those things you two mentioned — in-line images, embedded videos, tables, etc. — can all show up as intended by the sender.

I agree with you Julian. I think we'll need to tackle this piece by piece, but I'm on-board with the vision. I know this is what the users of Discourse want (they've been telling me!).

I wonder whether the most extensible way to do this is by sending markdown in addition to the HTML we already send. Markdown

• has canonical (word of the day) markup for media objects (e.g. we'll all send images as ![image](https://imageurl.com))
• is more secure than HTML
• is (mostly?) already supported by the platforms who'd want to federate with each other for this richer content.

If we put an additional markdown representation which included the richer content we'd also avoid the HTML being rejected or subject to parsing we don't control on the grounds it contained unsupported tags or overly-complex structures.

julian:

It depends on where the topic first started. If a topic started on i.e. SocialHub then it makes sense that the canonical URL should be SocialHub. If it started on the NodeBB community it should be that. This might've been implied in your post, but I wanted to make sure!

Yes, that is my understanding. For example, the canonical url of this topic would be

https://community.nodebb.org/topic/18050/how-do-you-use-context-if-at-all julian:

Secondly, it would not be correct to set a resolvable context as the canonical URL if that context resolves to an AP implementer following FEP 400e, unless you also keep track of whether all items in that context were Add'd and can confirm that all items are in that collection.

I'm not sure I quite agree here, albeit I may be misunderstanding your meaning. I don't think the "canonical" nature of the context should be dependent on the fidelity of the context's object (e.g. the context's collection) to all activities made with respect to it, or dependent on the context owner following a particular approach (beyond the necessities I've laid out below).

I feel like requiring activity fidelity makes the use of the context a bit too circumspect as there will always be a possibility that some actor interacting with it does not consider the context to have treated its activities appropriately.

Consider the following

• Discourse and NodeBB both consider the context of this topic (i.e. the one we're in right now) to be the canonical context, as represented in the canonical url

  https://community.nodebb.org/topic/18050/how-do-you-use-context-if-at-all

• Another platform, let's call it "SEOmaster" has also published some activities in this context, however for whatever reason they are not winding up in the context's collection, and not appearing in the topic representations on nodebb and socialhub. There could be many reasons for this, ranging from an issue with their activity formatting, to connection issues, to an issue with the actor etc.

• NodeBB has implemented FEP 400e compatibility, in addition to 1b12 support, in some form.

• SEOmaster, as its name implies, has amazing SEO. Because it doesn't consider its rejected activities to be treated appropriately. It feels justified in setting the canonical URL as a URL with its domain and points out that NodeBB is compatible with FEP 400e.

Now, the above could well happen anyway, without any justification, if SEOmaster were to ignore any convention we devise here. However I think the convention we set should be as robust as possible. Making it subject to the specific implementation of the context feels like a hostage to fortune to me.

That said, I do think that, to be considered a "canonical" context for the purposes of a forum the following needs to be true:

1. context is resolvable.
2. It resolves to a Collection.
3. The Collection has a resolvable url.

For a forum I think we need to at least require the context to be a Collection, otherwise it can't be a canonical context for a topic.

One context-related issue I've encountered which hasn't been canvased yet, is that context could be used to set the canonical url of a forum topic. When I say I've encountered this issue, it's some feedback we've received on the plugin. See further

And the subsequent discussion.

What I'm currently thinking is the following:

1. When working with a topic (thread etc)
2. If a Note in that topic has a resolvable context
3. If the context resolves to a Collection.
4. Use a resolvable URL for the Collection as the canonical url
   • My current candidate for a "resolvable url" is the url property of the Collection as the Discourse plugin already serializes the topic url as the url of Topic Collections.

Interested in thoughts on any of the above.

Hey guys, looking forwarding to seeing you at the meeting today. We have a new video-call url:

We're getting the link updated on our SocialCG event too.

julian:

This is where there is some potential to trailblaze as the other half of the equation might be implementing 7888, aka a resolvable context.

I have a feeling that context and target would work well to point to the same thing.

Agreed! The Discourse plugin treats them as equivalents, with a preference for context over target.

def create_collection(post) # See https://codeberg.org/fediverse/fep/src/branch/main/fep/400e/fep-400e.md # See https://socialhub.activitypub.rocks/t/standardizing-on-activitypub-groups/1984 raw_collection = object.context || object.target ... julian:

My assumption was that the surveys and spreadsheets would be helpful to guide discussion at WG meetings, but eventually lead to a SocialCG report of non-normative findings, followed by a recommendation for new implementors.

Also agreed, that is my thinking too. I just meant that when I was making the spreadsheet it occurred to me that it could also be the basis for an academic project. Perhaps I'm also just being lazy and thinking of who would be enthusiastic about and have the time to do this kind of thing comprehensively.

Great to see you here again!

grishka:

And it’s also fine to be incompatible

True! Albeit, I think the general consensus here is that there isn't an inherent incompatibility between 400e and 1b12. The question is more how an implementor approaches processing a Group actor's activities. @trwnh helpfully lays out the possibilities above

The point of this topic and the spreadsheet I just shared is not to contrast the two standards. It's more of an empirical reference of sorts for implmentors.

grishka:

you can’t exactly imagine Mastodon and a phpBB forum interoperating in any meaningful capacity simply because their user experiences are so disparate.

Well, I might slightly disagree with you there as Discourse, NodeBB and other forum-like implementations in the #activitypub:threadiverse-wg interoperate with Mastodon

silverpill:

Added “Yes (partial)” to FEP-1b12 column.

Thanks!

silverpill:

I intend to fully support both FEP-1b12 and FEP-400e in the future.

I think this is where the Discourse plugin will end up too.

Actually, now that I think of it, the Discourse plugin does partially support 400e as it will recognise a Collection in the target property. However it doesn't process Additions to such a collection, so saying it supports 400e is premature.

angus:

Implementations

https://docs.google.com/spreadsheets/d/159_K48ICn53IYOIr0KT39luVJCqBBmmpLeL6Puc7XLE/edit?usp=sharing

I've added an implementation spreadsheet and some prior discussions on this front for our June meeting.

@devnull By-the-by it strikes me that these implementation spreadsheets we're making should be synthesised in some way at some point. My gut is that this would make a good masters or PhD thesis for someone, i.e. a knowledge graph or onotology or something like that of the actual Fediverse (i.e. how it's actually implemented). We'd just need to find the right enthusiastic (and funded) academic...

@silverpill I was actually unclear on Mitra's approach to 1b12 and 400e. Would you mind adding in a Yes in the right column (and any notes) to the spreadsheet?

trwnh: Discourse may wish to include Like activities as part of the conversation (although I still think it probably shouldn’t) Could you elaborate specifically on why you think Like activities shouldn't be included? trwnh: there is a certain philosophy that activities are actions that manipulate “post” objects, and there is a different philosophy that takes activities to be the primary “post” I would say that you don't necessarily need one to be primary. Both can be relevant. What people do in a topic can be just as relevant as what people say in a topic. To give a small example, if I were to make a new topic in #activitypub:threadiverse-wg about Discourse's approach to HTML parsing, a Like from @devnull on that post is arguably more relevant to the topic than if a completely new user, unconnected to the Working Group came along and posted Hey guys, maybe the wrong place to post this, but I don't understand HTML! halp! That Note is arguably less "relevant" than Julian's Like. I'm not saying that Activities are primary over Objects, just that both may be relevant depending on the context. I don't particularly see the benefit in preferencing one over the other in a normative sense. That said, I do think that Objects are necessary as a baseline, as not all implementations will have the same feature set (some may not support likes for instance), so my view on this is a baseline of utility with support for additional, potentially relevant, content: The baseline to give the context collection utility is the presence of Objects; however Activities in the collection MAY be just as relevant in certain contexts and should be supported.

Thanks for starting this topic @devnull, I'll add Discourse's approach soon. trwnh: I’m not convinced it’s particularly important to have a complete backfilled view of every single like and share, or being able to construct an edit log with every single Create/Update. From the point of view of a casual consumer, that information can be lazy-loaded through checking the likes or shares collection; an optimization would be for the producer to partially embed a representation of those collections with a totalItems and maybe the first page, in order to support a “x, y, and 8 others liked this post” type of UX I agree with this, as a baseline. I think there might be a useful distinction here between MUST and MAY. It is necessary for the context collection to contain the base objects. It may be useful for the collection to contain other things for specific cases. For example, if I'm looking at Discourse to Discourse federation, I probably want to have the Likes in there. Perhaps if we establish that context collections will include the objects, and may include other things, if an implementation doesn't want to support those other things, they can filter appropriately. trwnh: I also think the ordering should be forward chronological instead of reverse chronological, but this is part of a larger issue with collections ordering and paging: Stricter specifications for pagination of Collections and OrderedCollections (btw, the assertion that “every OrderedCollection MUST be reverse chronological” has been somewhat recently clarified/relaxed to only the ones introduced in activitypub as OrderedCollection) – the ideal would be to be able to, as a consumer, request the collection with parameters for ordering, page size, and start index. But failing that, we could just fall back to a similar requirement of reverse chronology… although I dislike and hesitate to enforce this as a MUST. (The ship may have already sailed for this, but I likewise wish/think that the activitypub OrderedCollections were forward chronological instead of reverse chronological. there’s something conceptually backwards about the whole thing.) I agree with you, and did when I first read your topic on this, however I don't think we can intentionally violate the published spec, as it will lead to confusion (the solution will be worse than the problem). We have to work with it, or perhaps get it changed (if possible). But I agree with all of the spec-compliant recommendations you have in that topic. julian: If you see a Create(Note) you can't be certain it doesn't get Delete(Note)'d later on in the collection! True, albeit there might be circumstances in which you want to know there was a Note, but it has now been deleted. Like with receiving Activities to your inbox, I think we need to support both standalone Notes, and Notes wrapped in Activities. Standalone Notes as the "baseline", but accommodating the fact that Activity wrapping may occur.

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

trwnh: 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.

trwnh: 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.

In 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.

@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.

Yeah, 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.

I 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

The 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.

The 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