Some notes for things I want to bring up regarding agenda items:
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
Containers vs Collections
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> <contains> <#red_ball>.
<#Bag> <contains> <#green_ball>.
<#Bag> <contains> <#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.
Mapping to AS2-Vocab?
If we roughly map this to AS2-Vocab we might get something like this:
@id: <account>
@type: [as:Person, sioc:UserAccount]
@id: <moderator>
@type: [as:Person, sioc:UserAccount]
@id: <post>
@type: [as:Note, sioc:Post]
as:attributedTo: <account>
sioc:has_creator: <account>
as:content: "Hello"
sioc:content: "Hello"
as:context: <thread>
sioc:has_container: <thread>
@id: <thread>
@type: [as:Collection, sioc:Thread] # caveat where as:Collection has spec issues
as:attributedTo: <account>
as:audience: <forum> # maybe?
sioc:has_container: <forum>
sioc:container_of: <post>
@id: <forum>
@type: [as:Group, sioc:Forum]
as:attributedTo: <moderator> # i guess?
sioc:has_moderator: <moderator>
sioc:has_host: <site>
@id: <site>
@type: [as:Service, sioc:Site] # idk about this one
sioc:host_of: <forum>
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.
Comparison to NNTP / NetNews protocol / Usenet network
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 <CR-LF>.<CR-LF>
[C] From: "Demo User" <nobody@example.net>
[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 <CR-LF>.<CR-LF>
[C] From: "Demo User" <nobody@example.net>
[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: <notification>
actor: <you>
type: Announce
object: <your-post>
to/cc/audience/bto/bcc: <some-group>
id: <distribution>
actor: <some-group>
type: Announce
object: <your-post>
audience: [<some-group/members>, <some-group/followers>]
cc: <you>
but instead of addressing or targeting <some-group> you might instead address or target <some-thread>? whichever application is listening to the thread’s inbox then handles the cascade of distribution upward:
id: <post>
context: <thread>
id: <thread>
context: <forum> # ?
audience: <group> # ?
attributedTo: <author>
followers: <thread/followers>
id: <forum>
audience: <group>
followers: <forum/followers>
id: <group>
members: <group/members> # extension property/collection
followers: <group/followers>
what is desired is roughly this:
<you> Announce to the <thread>- the
<thread> Announces to…
<author><thread/followers><forum>?<group>?
- the
<forum> might also Announce to <group> and to <forum/followers>
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: <notification>
actor: <you>
type: Announce
object: <your-post>
to/cc/audience/bto/bcc: <thread>
# ... some chain of events later...
actor: <service>
type: Announce
object: <your-post>
to/cc/audience/bto/bcc:
- <author>
# - <thread> is already aware?
- <thread/followers>
- <forum>
- <forum/followers>
- <group>
- <group/members>
- <group/followers>
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
<you> to have to be aware of every single downstream/upstream recipient, right?