Re: 400e, 7888, and conversation containers

julian

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.

a

I don't think "obsolete" is the right framing here. You can mostly consider Conversation Containers to be a synthesis of 7888 and 400e, and if they dropped target on the object (invalid) and on the Create activity (undefined), then it would basically be 7888.

Mike Macgirvin 🖥️

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.

silverpill

@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/t/how-do-we-handle-groups-reconciling-fep-400e-and-fep-1b12/4088/41
(ap)

Erlend Sogge Heggen

silverpill1:

And I've come up with a plan for FEP-400e and FEP-1b12 convergence:

Would love to read more! Please provide a valid link.

julian

@[email protected] I believe you can access that here: https://socialhub.activitypub.rocks/t/how-do-we-handle-groups-reconciling-fep-400e-and-fep-1b12/4088/41

silverpill

@julian @erlend_sh Thank you, this is the correct link. The URL in my post leads to AP object, I forgot that Discourse doesn't redirect when you view those in the browser. It also doesn't seem to support Update activities

julian

@[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.

silverpill

@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

Mike Macgirvin 🖥️

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.

silverpill

@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.

silverpill

@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

infinite love ⴳ

@silverpill @mikedev @julian "partial embedding" is a red herring. all embeddings are partial embeddings as far as you know. even fetching from the origin isn't guaranteed to respond with all statements/properties. (open world assumption, remember?) and you're going to have to fetch from origin anyway because you can't trust non-authoritative representations.

i think you'd be better off indexing the collections.

silverpill

@trwnh @mikedev @julian If a relevant authority makes a claim about an object, I have no reason to not believe it. The default assumption is full representation, so if object is signed, or embedded within another object of the same origin, I wouldn't fetch it. Unless it is known to be partial - and that can be indicated by a special property, or can be required by some specification (as FEP-400e does).

infinite love ⴳ

@silverpill @mikedev @julian the default assumption should not be "full representation", because you can never have the entire set of knowable facts about a given subject.

what we should strive for instead is to make sure that any representation served is useful. this is not the same thing as it being "full". for example, there may be private attributes that are not being served.