Does context in AP have to be a collection, or can be be like a Flag activity? Say I wanted to Create(Note) about a Flag I'd received, I'd need

Emelia 👸🏻

Does context in AP have to be a collection, or can be be like a Flag activity? Say I wanted to Create(Note) about a Flag I'd received, I'd need:

1) A way to address the remote moderation team (moderation group actor)

2) A way to say "this note is about this Flag activity", using inReplyTo would feel weird here, but maybe context would work?

Scott M. Stolz

I thought that it could be used for that until I participated in a discussion about threads.

Scott M. Stolz

@Emelia

I thought it could be used for that until I participated in a discussion about threaded conversations.

#^https://community.nodebb.org/topic/18364/fep-convergence-400e-7888-171b-conversation-containers-76ea

If I am understanding them correctly, they are claiming that context should be assumed to be a thread and not used for anything else.

cc: @julian @infinite love ⴳ @Evan Prodromou

Emelia 👸🏻

@scott oh no.. *sigh*

Emelia 👸🏻

@scott hmmm, I guess context is completely undefined right now, so am wondering if it'd make sense to just use it. "these Notes exist in the Context of this Flag activity"

infinite love ⴳ

@scott nope, context can be anything; it doesn't have to be a collection. it's only a thread *if* it has whatever properties you consider necessary for a thread (e.g. an owner, items, and some signal that you can participate)

for the example of Create Note regarding a Flag, i'd use inReplyTo because you are responding to the report, no?

cc @ThisIsMissEm @julian @evan

infinite love ⴳ

@thisismissem @scott you could do that if you wanted the notes to be grouped around that Flag activity

Emelia 👸🏻

@trwnh @scott @[email protected] @julian @evan

I wanted to avoid inReplyTo since subsequent replies wouldn't share the same parent, i.e., Flag -> Note 1 -> Note 2

Note 2 would be inReplyTo Note 1, but both would be in the context of Flag

infinite love ⴳ

@[email protected] @scott @ThisIsMissEm @julian @evan makes sense to me

Emelia 👸🏻

@trwnh @scott that's the idea, I think, because you might have a note on a Flag go to mod team A, and another to mod team B (for a Flag addressed to multiple mod teams)

Emelia 👸🏻

@trwnh @scott @[email protected] @julian @evan

I do also want to introduce correct addressing on Flags as currently they don't carry to/cc/bto/bcc, they're just sent to the reported accounts inbox, and Mastodon passes them all through to the moderators, without the reported account seeing those activities, despite them being implicitly addressed to the reported account (by means of delivery to their inbox)

Jenniferplusplus

@thisismissem semantically, yes, it can be a flag or anything else you want. Functionally, for real world implementations? ‍️

I'm trying to think through what letterbook would do, and I suspect it would do the right thing. At least at the point of receiving the message. I would need some logic in reports to connect them back to that context, but i think that's likely to be straight forward

Jenniferplusplus

@thisismissem what I really want is context to be

1. A stable identifier that I can index
2. An indicator of whether and how reply control is implemented
3. A collection of related content-like objects, if reply control is implemented

In that order.

I think using a Flag (or its ID) satisfies that

Scott M. Stolz

@infinite love ⴳ

nope, context can be anything; it doesn't have to be a collection. it's only a thread *if* it has whatever properties you consider necessary for a thread (e.g. an owner, items, and some signal that you can participate)

The problem is that there is an assumption that things with those traits are a thread, which is not necessarily the case.

If you have a thread and a collection that can both be participated in, then how will you figure out which is the thread and which is the collection? As I stated before, there should be a way to specify which context is a thread instead of just assuming based on some random traits it might have.

Emelia 👸🏻

@jenniferplusplus yeah, I don't think we'd have a collection for notes on a flag though, because the notes would be directly addressed to group actors for the moderation teams

Only use case I could think of is maybe inviting another moderation group actor to the thread of notes on a Flag, but that feels a bit weird with permissions.

Jenniferplusplus

@thisismissem Which is fine. If it's a collection, that makes it useful as a place to retrieve notes/etc that I didn't directly receive. But in this case it's overwhelmingly likely that there would only be 2 servers involved in the discussion anyway. So that's fine.

Emelia 👸🏻

@jenniferplusplus also, in Mastodon I'm probably separating the Flag activities from the report as one Flag activity can now generate multiple Flag activities with varying content (user forward vs mod forwarded with content overwritten)

Emelia 👸🏻

@jenniferplusplus even if it's 3-way plus, it'd have to all be directly addressing to avoid note leakage to as:Public

julian

@[email protected] @[email protected]

For what it's worth, @[email protected] 's FEP 7888 doesn't explicitly define what context means semantically with regard to other objects, so to use it for flag reports makes complete sense to me. I don't know where @[email protected] is getting the idea that context is only for threads, but given that it was discussed under the umbrella of the "threaded" discussion WG, I can see why one might make that assumption.

Were I to implement this in NodeBB, each individual Flag activity would be translated to a NodeBB "report", and they'd contain a context, which is the flag itself.

With regard to your concern re: addressing, if you queried the context, you'd get an OrderedCollection containing objects that you have access to view, but since in NodeBB only moderators can view flag reports, anybody querying it over ActivityPub would just get an empty collection.

cc @[email protected]

Emelia 👸🏻

@jenniferplusplus https://github.com/swicg/activitypub-trust-and-safety/issues/14#issuecomment-2438725574