@scott@authorship.studio ah, but we do, and like I said earlier, NodeBB achieves this by following the audience property aspect of FEP 1b12, which is in use by several other implementations already.

A NodeBB post is part of the topic/thread context, and it is also part of a category, just like your "projects". Different name, same thing (more or less).

cc @trwnh@mastodon.social

@julian @scott i am slightly dissatisfied with how `audience` ended up being used because i don't think a Group actor is necessarily the best way to model a forum category, but i think it could make sense to say that the `context` of a "post" is a "thread", and then extend that by saying that the `context` of a "thread" is a "category". you have similar concerns between posts and threads as you do between threads and categories, just "one level up".

@julian @scott the reason i say this is because membership in a Group is not yet defined (so it looks like only one actor is in the audience instead of the implication of several actors). also, the audience of a thread may differ from the audience of a category in some systems. you might *generally* expect that for any "post", `audience` == `context.audience` == `context.context.audience`... but this cannot be a guarantee.

@julian @scott one other thing i want to allude to briefly but not get into right now: forum category hierarchy.

@trwnh@mastodon.social @scott@authorship.studio

@trwnh@mastodon.social said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):

i am slightly dissatisfied with how audience ended up being used

I am as well, although I was willing to implement it for the sake of compatibility until a better solution arrived.

While I alluded earlier that a NodeBB post could have multiple contexts (the topic and the category), it is better described by levels. Posts in Topics, Topics in Categories.

I suppose then a context would have a context. Makes sense to me.

@julian

While I alluded earlier that a NodeBB post could have multiple contexts (the topic and the category), it is better described by levels. Posts in Topics, Topics in Categories.

This is similar to how a project management system would have multiple levels, like project, task list, task, subtask, etc. And you could associate a thread or a post to any one of those. So it is similar to hierarchical categories in that way.

@julian

I am as well, although I was willing to implement it for the sake of compatibility until a better solution arrived.

Other than telling people that their post was boosted by the forum, do other platforms actually use the categories that we assign to posts?

If not, what is holding us back from creating something new for categories?

@infinite love ⴳ

i am slightly dissatisfied with how `audience` ended up being used because i don't think a Group actor is necessarily the best way to model a forum category,

I agree. I would expect audience to be the audience and not a collection of posts or a group actor.

@scott@authorship.studio said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):

If not, what is holding us back from creating something new for categories?

Nothing. Being able to traverse remote contexts would be absolutely wonderful, and is in line with my goals for the ForumWG.

However that comes after we hammer down a solid recommendation for conversational contexts. Let's hold off for now, we'll get there.

@julian But if we decide to use contexts for categories, it would be relevant, since we would need to anticipate that usage pattern.

Even if we don't decide how we will present categories now, we probably should anticipate that people will use context in ways other than to represent a conversation container.

@scott@authorship.studio whether we decide to use as:context or not to represent second-order collections is still to be determined, but we can hold off on that until we figure out first-order collections. I'm not saying we hold off on it for years, just months.

FEP 7888 doesn't disallow other uses of context. It just gives direction for implementors who wish to use it to represent a first-order collection of objects. The key here is whether that context is resolvable to a collection, and (maybe) whether that collection contains items of interest (as:Note-like objects or otherwise).

The ForumWG with input from other interested parties (@erincandescent@akko.erincandescent.net, @trwnh@mastodon.social, among others) have provided an oral history that suggests that as:context is effectively unused, and what usages are found in the wild already conform to FEP 7888.

Do I think as:audience is the solution to second-order collections? No. It's just the way it is now, but not the way it will be forever.

@julian @scott @trwnh depending upon how strictly you interpret the SHOULDs of 7888 we can approximate that 1% of posts today are using context per 7888, assuming post count is proportional to user count

@erincandescent @scott @julian i wonder if it makes sense to define something akin to conformance profiles or compliance levels? i held off on doing this because there aren't any MUSTs in there, but you could loosely say the following:

a "level 0" producer doesn't use context
a "level 1" producer uses an opaque id
level 2: it resolves to an object
level 2.1: it resolves to a collection
level 2.2: it resolves to a collection with an owner
level 3: sending objects to the owner may add them

@erincandescent @scott @julian mastodon etc are "level 0", pleroma/akkoma are "level 1", nodebb and discourse are somewhere around 2-3

@trwnh @scott @julian 1.5. the ID isn't dereferencable but could be (Pleroma & Akkoma are here)

@infinite love ⴳ @julian @Erin

Do we need to indicate whether you can follow a context, or would that be specified elsewhere?

@scott @julian @trwnh general rule: you should be able to follow anything which has an outbox and inbox

(The inbox is necessary to send the follow activity to)

@Erin @julian @infinite love ⴳ

So, since it is not declared, we would need to check to see if the context has an inbox and outbox.

And since it is not declared, we would have to check to see what traits a particular context has.

And since it is not declared, we would have to make assumptions about whether a context is a thread (conversation container) or not.

It seems like we are doing a lot of checking when the sending platform could just tell us that information.

Sure, we can't assume they will provide that information, but if they tell me up front, that is one less server query I got to make since an if then statement can make that extra query go away.

@scott @julian @trwnh I'm not sure I completely follow the specifics of what you're trying to discuss here, but ActivityPub is duck-typed: if it quacks like a duck, it's a duck. If it has the endpoints you need to follow it, you can do so.

If a post has an inbox and an outbox, you can follow it. If a picture has an inbox and outbox..

Something like this:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "thr": "https://purl.archive.org/socialweb/thread#",
  "thread": {
    "@id": "thr:thread",
    "@type": "@id"
  },
  "root": {
    "@id": "thr:root",
    "@type": "@id"
  }
  "traits": {
    "traits": "inbox, outbox, conversation, amendable"
  }
}

This would let me know that it is a thread and that people can follow the context. I can then render it as a thread and potentially add a follow or subscribe button for the context.

You could also declare that it does not have an inbox and outbox, which saves me the trouble of checking myself.

@erincandescent @scott @julian ideally you would also check for the presence of a followers collection, but fedi kind of has this bad habit of assuming things

like, going by duck typing, i would say that

- followers means you can Follow it
- likes means you can Like it
- shares means you can Announce it

but we just throw the firehose around and let the recipients sort it out

part of the issue is that activities are both notifications and also actions with side effects