Forums and Threaded Discussions Task Force

0 readers

2 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 7 months ago

Re: 400e, 7888, and conversation containers (community.nodebb.org)

submitted 4 months ago by [email protected] to c/[email protected]

7 comments fedilink hide all child comments

Did @[email protected] or @[email protected] put together a draft FEP that successfully merges 7888, 400e, and @[email protected]'s conversation containers? I remember reading it last week, and wonder if it's the one true FEP that will render the others obsolete.

top 7 comments

sorted by: hot top controversial new old

[–] [email protected] 1 points 4 months ago (1 children)

@julian @trwnh @mikedev

There is a draft of Conversation Containers FEP: https://codeberg.org/silverpill/feps/src/branch/main/171b/fep-171b.md
And I've come up with a plan for FEP-400e and FEP-1b12 convergence: https://socialhub.activitypub.rocks/ap/object/e9b7fb34c4af9291b9b98095e661789d

[–] [email protected] 0 points 4 months ago (2 children)

@[email protected] Thanks for sharing this. I'm confused by these two sentences:

Collection type SHOULD be Context. ... Add.target MUST be a partial representation of the collection. Thus, if type of the collection is Context, any Add activity modifying that collection can be identified by Add.target.type.

My context collection is of type OrderedCollection. I don't believe Context is one of the AS2 core types.

I don't see any reference to collection type being Context in @[email protected]'s original document.

[–] [email protected] 1 points 4 months ago

@julian @mikedev Yes, this is a new requirement, but I can't comment on that part yet. The FEP is very much work in progress

[–] [email protected] 1 points 4 months ago (1 children)

That wasn't in my original doco and I'm not using it currently. I'll need to see what problem is solved by having Context before I offer an opinion.

I recall @[email protected] took issue with the fact that 'context' and 'target' are the same object and he felt this was duplicitous. There's also a bit of an issue that a "partial object" (defined in FEP-400e) isn't really defined anywhere in the base specs either - and perhaps using Context will help resolve that.

Since it's a SHOULD, my original implementation is arguably compliant with the FEP without it.

[–] [email protected] 1 points 4 months ago (1 children)

@mikedev @trwnh @julian

Context helps with identifying the target. When I receive an Add activity, I need to know what collection is being modified. Is it a featured collection, a context, or something else?

One solution is to keep an index of all known collections and search through it every time Add is received.
Another solution would require cooperation from producers, but I think it is a bit cleaner: embed partial representation of a target and use specific type there, like Context, instead of Collection. Then, as a consumer, I can simply check target.type instead of searching for target.id in my collection index.

[–] [email protected] 1 points 4 months ago

@trwnh @mikedev @julian This object design pattern (partial embeddings) can be used in other situations too. We can use a new property like partial: true do indicate partial representations:

https://socialhub.activitypub.rocks/t/partially-embedded-objects/4450

[–] [email protected] 1 points 4 months ago

https://codeberg.org/silverpill/feps/src/branch/main/171b/fep-171b.md

It isn't so much "one FEP to rule them all" as it is that Conversation Containers stands on the shoulders of giants.