@thisismissem@hachyderm.io let’s assume no. Only common property is toot.

I just want to make sure it’s not going to make fedify or smithereen throw errors when it tries to parse my janky @context.

Hi @scott@authorship.studio, 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 @trwnh@mastodon.social’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, @renchap@oisaur.com, 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?

@scott@authorship.studio 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.

@scott@authorship.studio 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 @trwnh@mastodon.social are splitting hairs and really want the same things.

@thisismissem@hachyderm.io @trwnh@mastodon.social @silverpill@mitra.social 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.

@silverpill@mitra.social 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.

@silverpill@mitra.social 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.

@thisismissem@hachyderm.io 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 @leroy@indiehackers.social . 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

@erincandescent@akko.erincandescent.net @trwnh@mastodon.social 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).

@darius@friend.camp @erincandescent@akko.erincandescent.net keep in mind we’re talking about as:context and not @context

@thisismissem@hachyderm.io done thanks! Appreciate the offer. There’s a meeting link attached or we can just hop on the CG link. Either way is good.

@darius@friend.camp 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!

@silverpill@mitra.social 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 @mikedev@fediversity.site’s original document.