Hi @[email protected], thanks for your thoughts. I took the evening to think it over.

I agree that using thr:thread would be the most explicit way of signalling that NodeBB topics are threads, and if 76ea were to be adopted by a majority of implementors, then I would reconsider. Currently I am on the fence about whether or not I should implement it.

I do want to point out that @[email protected]’s FEP 7888 doesn’t expressly forbid multiple contexts, and I think upthread they even said that such a use case would not be contrary to the FEP:

based on this conversation i probably need to add examples to fep-7888 of how one might process multiple contexts. ~ trwnh

My opinion today is that when NodeBB uses context, it is doing so to signal that “hey, these posts are part of this collection”, and exactly nothing more. It is up to the receiving end to decide how to implement it, and I think that this sort of variety is absolutely wonderful.

If, for example, someone were to see my context and say “I’d like to map this context’s objects out into a word cloud and do sentiment analysis on it”, I think that’s a perfectly cromulent use of the data. For me to say “this here is a thread, and you better treat it as a thread” is contrary to the spirit of ActivityPub and fedidevs in general.

It would be like the ForumWG saying to Eugen, @[email protected], et al. that “we’ve decided that YOU, Mastodon, need to support as:Listen and render inline players, and playlist support, etc.”. That’s ridiculous, wouldn’t you agree?

@[email protected] said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):

I am not sure what you are going to do when there are multiple collections associated with a post.

My plan is to take the first item in context and treat that as the most narrowly scoped collection containing that object. The assumption is that the contexts are ordered from narrow-to-wide. Whether or not additional contexts would be helpful is irrelevant to me, as I am converting this object into a NodeBB topic only.

You can make arguments that this is not correct. I will not disagree. I will simply say that, like it or not, this is the simplest form of compliance most implementors will opt for.

@[email protected] Yes. Per 1b12, audience is the appropriate property to use to denote a collection of loosely-related objects. context is ideal for closely-related objects (like ones that share a reply tree, but that doesn’t rise to the level of a requirement), like posts in a context (topic/thread).

In your examples, the “thread” is a Collection when resolved and is referred to in objects via context. The “category” is an Actor when resolved, and is referred to in objects via audience.

As for the other conversation, it honestly seems like you and @[email protected] are splitting hairs and really want the same things.

@[email protected] @[email protected] @[email protected] Ah seems I misunderstood the assignment then heh

In that case the context collection would contain the note objects as you specified in the other topic.

Right now NodeBB’s context resolver expects a Collection-ish type, so finding a Flag would cause it to back out — for now at least.

@[email protected] said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):

Do you have something like that in NodeBB? I wonder how others solve this “routing” problem

We do the same. We don’t actually handle Adds right now, but our Update handler has a switch..case based on type.

Adding a separate type would be easier, yes. Otherwise you’re looking at additional logic to tease apart different variants that share the same base object type. For example, the logic for Update(Note) has further logic paths depending on whether the note is publicly addressed or not.

So then yes, a Add{target: Collectionish} might be vague, but that’s only the case if other implementations use the same.

@[email protected] said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):

It is for easier identification of conversation-Add activities. My server may receive many different kinds of Add activities, and it would be nice to have some indication of what collection is being modified.

In that case, are you trying to sidestep a potential future conflict? I think I can see your rationale that duck typing “resolved context is a Collection” may not be specific enough, but I am not currently aware of anybody outside of 400e/7888 that has a context that even resolves to anything.

@[email protected] Yes, I’ve noticed that Megalodon also doesn’t support blockquotes, but the web client definitely does (I just checked hachyderm), which is a great start.

This also reminds me of a discussion I had way back when I first joined fedi, with @[email protected] . When mocking up a forum-like frontend for ActivityPub data*, he actually rendered the content of the inReplyTo as a blockquote before the reply, which is actually quite an interesting use-case for inReplyTo!

* Also, is there anything more indie hacker than that? lol

@[email protected] @[email protected] Right, it gets a little confusing when implementors inherit context from the objects they’re replying to (or maybe the root node?), but that’s exactly what 7888 tries to codify/demystify.

But Akkoma’s use of context seems to be in line with 7888 (in that it’s pointing back to the resolvable context provided by NodeBB).

@[email protected] @[email protected] keep in mind we’re talking about as:context and not @context

@[email protected] done thanks! Appreciate the offer. There’s a meeting link attached or we can just hop on the CG link. Either way is good.

@[email protected] just added an open floor item for tomorrow’s WG meeting to discuss Harvard’s Applied Social Media Lab (https://asml.cyber.harvard.edu/)

Looking forward to it!

@[email protected] Thanks for sharing this. I’m confused by these two sentences:

Collection type SHOULD be Context. … Add.target MUST be a partial representation of the collection. Thus, if type of the collection is Context, any Add activity modifying that collection can be identified by Add.target.type.

My context collection is of type OrderedCollection. I don’t believe Context is one of the AS2 core types.

I don’t see any reference to collection type being Context in @[email protected]’s original document.