Some notes for things I want to bring up regarding agenda items:

SIOC: Semantically Interlinked Online Communities as prior art

Predates ActivityPub, was submitted to the W3C, has evolved up until ~2018 in some form. Concepts that could be relevant for Forum TF work:

sioc:Item is directly associated with a sioc:Container, whereas as:Object is included in an indirect list of items within as:Collection

For more on the difference between a Container and a Collection, see RDF Schema sections 5.1 and 5.2

A Container has open membership. There might always be more items in a container that are unknown:

<#Bag>  <#red_ball>.<#Bag>  <#green_ball>.<#Bag>  <#blue_ball>.# We do not know if the bag contains any other balls, such as a yellow ball.

A Collection can have closed membership. For example, Lists can be terminated with a nil element.

<#List> rdf:first <#A>.<#List> rdfs:rest rdf:nil.# We know that the list does not contain any more elements beyond A.

The way this is applied in SIOC is like so:

<#Item> sioc:has_container <#Container>.<#Container> sioc:container_of <#Item>.

The way this is applied in ActivityStreams is like so:

<#Collection> as:items (<#Item>).# There is no way to signal that the Item is part of the Collection, and it is not expected that collection items will expose links back to every single collection they are a part of.

sioc:UserAccount, sioc:Post, sioc:Thread, sioc:Forum, sioc:Site

• A Post has_creator UserAccount.
• A Post has_container which can be directly a Forum, or it can be something like a Thread (which can itself has_container of a Forum).
• A Forum can has_parent of another Forum, if wishing to model subforums.
• A Forum can has_space of a Space (like a desktop or file share), or in more concrete cases can has_host of a Site.

If we roughly map this to AS2-Vocab we might get something like this:

@id: @type: [as:Person, sioc:UserAccount]@id: @type: [as:Person, sioc:UserAccount]@id: @type: [as:Note, sioc:Post]as:attributedTo: sioc:has_creator: as:content: "Hello"sioc:content: "Hello"as:context: sioc:has_container: @id: @type: [as:Collection, sioc:Thread] # caveat where as:Collection has spec issuesas:attributedTo: as:audience:  # maybe?sioc:has_container: sioc:container_of: @id: @type: [as:Group, sioc:Forum]as:attributedTo:  # i guess?sioc:has_moderator: sioc:has_host: @id: @type: [as:Service, sioc:Site] # idk about this onesioc:host_of: 

Subtypes of forums and posts

From SIOC types module:

• Forum: ArgumentativeDiscussion, ChatChannel, MailingList, MessageBoard, Weblog.
• Post: BlogPost, BoardPost, Comment, InstantMessage, MailMessage, WikiArticle.

Protocol considerations

We probably want to separate eventually the idea of "i authored this" from "i have authority over this", especially if a forum "lives" somewhere on a host.

RFC 5536 defines an article format for sharing RFC 822/2822/5322 style Internet Messages with mandatory headers:

• Date (as:published)
• From (as:attributedTo)
• Message-ID (@id)
• Newsgroups (as:audience??)
• Path (no analogue, represents the path taken as the article is shared across newsgroups? so an ordered list of where it was shared/reshared from?)
• Subject (as:name or as:summary, but probably not required for AP Forum TF)

RFC 5537 describes architecture for distributing such articles as Internet Messages:

• A "posting agent" passes an article to an "injecting agent"
• The "injecting agent" injects the article into a group
• A "reading agent" can then fetch articles from a group

RFC 3977 describes NNTP protocol:

 Example of a successful posting: [C] POST [S] 340 Input article; end with . [C] From: "Demo User"  [C] Newsgroups: misc.test [C] Subject: I am just a test article [C] Organization: An Example Net [C] [C] This is just a test article. [C] . [S] 240 Article received OK Example of an unsuccessful posting: [C] POST [S] 340 Input article; end with . [C] From: "Demo User"  [C] Newsgroups: misc.test [C] Subject: I am just a test article [C] Organization: An Example Net [C] [C] This is just a test article. [C] . [S] 441 Posting failed Example of an attempt to post when posting is not allowed: [Initial connection set-up completed.] [S] 201 NNTP Service Ready, posting prohibited [C] POST [S] 440 Posting not permitted

We could probably do something with Announce and/or Offer or similar?

In a simple model where there are only groups and posts, no threads (a la FEP-1b12)

• Offer Note to Group
• Group can then accept/reject the post and issue an Announce?

Once we introduce threads, we will want to have more control not at the group level but at the thread level.

There is a bit of a philosophical question of approach here -- given that the core mechanism here is fundamentally notification messages via LDN (POST to inbox), although it is arguable that Activity payloads gets used as a sort of JSON-RPC more than as a notification... should we therefore optimize for a notification-oriented flow or a more procedural flow instead?

In a notification flow, we just want some resource to be aware that we have made a new post, and they can then distribute it or not. Say something simple like this:

id: actor: type: Announceobject: to/cc/audience/bto/bcc: id: actor: type: Announceobject: audience: [, ]cc: 

but instead of addressing or targeting you might instead address or target ? whichever application is listening to the thread's inbox then handles the cascade of distribution upward:

id: context: id: context:  # ?audience:  # ?attributedTo: followers: id: audience: followers: id: members:  # extension property/collectionfollowers: 

what is desired is roughly this:

• Announce to the
• the Announces to...
  • ?
  • ?
• the might also Announce to and to

the challenge is in avoiding duplicate traffic, so ideally this would be under the control of a single controller who issues a single Announce to the sum total of the accumulated audience:

id: actor: type: Announceobject: to/cc/audience/bto/bcc: # ... some chain of events later...actor: type: Announceobject: to/cc/audience/bto/bcc: - # -  is already aware? -  -  -  -  -  - 

this is essentially an event driven architecture. you'd need to choose between "exactly once" and "at least once" delivery.

concerns:

• what ends up in shares collection? for a single share action, do we end up with multiple Announce activities in there?
• who gets addressed? inbox forwarding? this probably shouldn't be the responsibility of to have to be aware of every single downstream/upstream recipient, right?

A note that the ForumWG meeting is scheduled to begin shortly: https://meet.jit.si/ap-forum-wg