Forums and Threaded Discussions Task Force

0 readers

1 users here now

Discussion and announcements related to the SWICG Forums and Threaded Discussions Task Force.

This profile is a discussion forum category and shares content from users who post in its discussions.

founded 4 months ago

FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea) (community.nodebb.org)

submitted 3 weeks ago by [email protected] to c/[email protected]

25 comments fedilink hide all child comments

Related to the ForumWG topic of resolvable context collections, there are four FEPs that are currently in consideration:

@[email protected] made a suggestion last month to hopefully reduce the number of moving parts:

Both FEP-400e and FEP-1b12 implementations: support FEP-7888 (context collection)

FEP-400e implementations: upgrade to Conversation Containers

FEP-1b12 implementations: add target property to Announce activity that points to context collection.

This takes FEP 400e out of the running (potentially). But the day after that last meeting, @[email protected] put together FEP 76ea, and now we're back to three.

My concern is that all three FEPs (7888, 171b, and 76ea) all share these distinct qualities:

They establish a conversational context for a given object
They federate out an Add on collection addition. (76ea also sends Remove)
They contain some concept of a context owner (attributedTo)

They differ on the following qualities:

7888/171b use context whereas 76ea uses a new property thr:thread
171b specifies a new object type Context
Collection items:
- 7888 sends objects in chronological order
- 171b sends activities in chronological order
- 76ea sends objects in reverse chronological order

In the lead up to the November WG meeting I'd like to address those differences. All three FEPs are in pre-draft or draft stages, and so I am hoping we can find some common ground and compromise.

Pinging interested parties (who were not already mentioned above) for comment:

@[email protected] @[email protected] @[email protected] @[email protected]

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 3 weeks ago (1 children)

@julian

No, that's for target property. Here's an example of Add.target from Streams:

"target": {
  "id": "https://streams.lndo.site/conversation/ed4775f8-18ee-46a5-821e-b2ed2dc546e8",
  "type": "Collection",
  "attributedTo": "https://streams.lndo.site/channel/red"
},

In my code I have a handler for Add activity, which then sends activity to one of the other handlers:

- Add{target: featured}
- Add{target: subscribers}
- Add{target: context}

Currently I use heuristics to determine which one to use. But with Add.target.type == <meaningful type name> the code would be simpler and less fragile.

Do you have something like that in NodeBB? I wonder how others solve this "routing" problem

[–] [email protected] 0 points 3 weeks ago (1 children)

@[email protected] said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):

Do you have something like that in NodeBB? I wonder how others solve this "routing" problem

We do the same. We don't actually handle Adds right now, but our Update handler has a switch..case based on type.

Adding a separate type would be easier, yes. Otherwise you're looking at additional logic to tease apart different variants that share the same base object type. For example, the logic for Update(Note) has further logic paths depending on whether the note is publicly addressed or not.

So then yes, a Add{target: Collectionish} might be vague, but that's only the case if other implementations use the same.

[–] [email protected] 1 points 3 weeks ago

@julian This pattern can also be used in Accept and Undo activities:

{
  "type": "Undo",
  "id": "https://social.example/activities/undo/1"
  "object": {
    "type": "Like",    # or "Follow"
    "id": "https://social.example/activities/like/1"
  }
}