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
-
@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.
-
@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)
-
@jenniferplusplus even if it's 3-way plus, it'd have to all be directly addressing to avoid note leakage to as:Public
-
@[email protected] @[email protected]
For what it's worth, @[email protected] 's FEP 7888 doesn't explicitly define what
contextmeans 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 thatcontextis 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
Flagactivity 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
OrderedCollectioncontaining 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. -
Emelia 👸🏻replied to julian last edited by [email protected]
@julian @jenniferplusplus @trwnh @scott @evan well, we'd be sending Create/Update Note about a Flag, so thinking context would be that Flag on the Notes
Not necessarily with a collection of notes about the Flag
-
@[email protected] that's fair, I don't know how we handle federating flag reports right now (as @oplik0/@[email protected]) handled that aspect.
Having the context contain the individual notes regarding a flag would also work.
-
@julian @oplik0 @opliko I'll have to take a look for: https://github.com/swicg/activitypub-trust-and-safety/issues/14
-
@scott i still don’t think “thread” is anything special or different than “group of posts bound together by a topic and audience and owner that you can submit your post to for consideration of being added”. if anyone can come up with a proper semantic definition of “thread” then i’ll consider revising my definition, but asking “which one is the thread” is a bit like asking “which one of these recipients is the audience”, or like saying you only work with Note and not Article.
-
@scott like, you could define a type Conversation that the creator of the “thread” specifies when creating the “thread”. but this type doesn’t change any of the processing considerations for anyone wanting to participate. it just hints the author’s intention.
the one thing it *might* also do is signal that a certain protocol is in place, for example, something is a “fep-xxxx Conversation” might come with additional restrictions or requirements… but you still need the other props to be present.
-
infinite love ⴳreplied to Jenniferplusplus last edited by
@jenniferplusplus @thisismissem i think you’re in luck because it’s at least guaranteed to be 1. that’s the “intended usage” per the spec and per how it got implemented.
2 requires you to be able to dereference that stable id from 1, but it doesn’t require any specific type or repr. it just needs an owner and some properties signaling who can participate and how.
3 requires the dereferenced object in 2 to specifically be a collection.
Flag as context works for grouping but not backfilling.
-
@infinite love ⴳ The biggest difference is that one is a conversation, with people replying to each other. The other is a list of random posts, most likely curated by a third party, and that may contain multiple threads.
Unlike Mastodon and other non-threaded platforms, on a forum, it is expected that EVERYONE in the conversation can see all of the posts in that conversation. It is a group experience in which everyone has context surrounding the conversation.
Compare that with random curated lists where posts and threads are taken out of context and added to a list. You can have multiple threads, individual posts, even other actions like likes and votes.
So the biggest difference is, not ironically, context. -
@scott if it’s “random posts” then it wouldn’t be a context, it would just be a collection. context requires purpose. the person authoring the object declares a context (or contexts) as a way to signal why their object exists. objects don’t exist to be added to random collections.
basically there’s two sides to it. the post author chooses which context(s) they want to declare. and the context owner(s) choose whether to add that post.
the browser can load any context they want to browse.
-
@scott when it comes to participating in a “thread”, you don’t do this from the object view. you need to navigate to the collection view first. it’s up to any individual actor to decide which (if any) context(s) they want to consider a “thread” or not.
-
@trwnh @jenniferplusplus yeah, and jn the context of comments on a Flag that are directed at you, I don't believe there'd be a need to backfill?
-
Here is an example:
id: post 1
context: thread-1, project, flag-a
id: post 2
context: thread-1
id: post 3
context: thread-2, project
id: post 4
context: thread-2, flag-b
id: post 5
context: project, thread-3, flag-a
etc.:
How do I know which one is the conversation that is displayed on the forum? -
Here is an example:
id: post 1
context: thread-1, project, flag-a
id: post 2
context: thread-1
id: post 3
context: thread-2, project
id: post 4
context: thread-2, flag-b
id: post 5
context: project, thread-3, flag-a
etc.:
How do I know which one is the conversation that is displayed on the forum?
@infinite love ⴳ Or more specifically, how do I know which is the official moderated version of the conversation according to the forum? -
@scott whichever one declares the requisite properties (owned by the forum or some mods on it, scoped to an audience, contains "post" objects bound to a context, etc.) -- if there are any missing properties that you consider "required", then you drop it from consideration.
for example, maybe you consider the "thread" as something special that needs to be declared, e.g. as a ConversationContainer, but i think that's needlessly limiting and not backwards-compatible with unaware implementations.
-
@scott the core functionality is the grouping of posts by their topic or shared context. the "trick" is that if it's a collection, it's actually entirely up to the owner to decide what goes in there! i could create a collection, declare it to be a ConversationContainer, but then start adding unrelated posts. actually, as the owner, i get to decide what's related and what's not! maybe i require context to be set. maybe i require inReplyTo. maybe i have some other criteria. ideally, i signal this.
-
@scott so the collection has some "participation criteria" which describes the shape of what i deem worthy of potentially Adding. for example, i could say that
- object.content must be present
- object.attributedTo must be present and included in the Collection.audience
- object.context must include Collection.idbut this is advisory at best. i reserve the right to add objects that don't match this shape.
i also can hint how i think the collection should be displayed, but this is only a hint.
