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.
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.
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] 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 isContext
, anyAdd
activity modifying that collection can be identified byAdd.target.type
.My context collection is of type
OrderedCollection
. I don’t believeContext
is one of the AS2 core types.I don’t see any reference to collection
type
beingContext
in @[email protected]’s original document.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.
Context
helps with identifying thetarget
. When I receive anAdd
activity, I need to know what collection is being modified. Is it afeatured
collection, acontext
, 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 atarget
and use specific type there, likeContext
, instead ofCollection
. Then, as a consumer, I can simply checktarget.type
instead of searching fortarget.id
in my collection index.@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