Re: 400e, 7888, and conversation containers
from julian@community.nodebb.org to swicg-threadiverse-wg@community.nodebb.org on 23 Sep 2024 16:47
https://community.nodebb.org/post/101096

Did @silverpill@mitra.social or @trwnh@mastodon.social put together a draft FEP that successfully merges 7888, 400e, and @mikedev@fediversity.site's conversation containers? I remember reading it last week, and wonder if it's the one true FEP that will render the others obsolete.

#400e #7888 #fep #swicg-threadiverse-wg

threaded - newest

mikedev@fediversity.site on 23 Sep 2024 19:48 next collapse

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.

trwnh@socialhub.activitypub.rocks on 23 Sep 2024 17:19 next collapse

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.

silverpill@mitra.social on 23 Sep 2024 23:08 collapse

@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

erlend_sh@socialhub.activitypub.rocks on 30 Sep 2024 19:40 next collapse

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@community.nodebb.org on 30 Sep 2024 19:16 collapse

@erlend_sh@socialhub.activitypub.rocks 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@mitra.social on 30 Sep 2024 19:44 collapse

@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@community.nodebb.org on 01 Oct 2024 15:20 collapse

@silverpill@mitra.social 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 @mikedev@fediversity.site's original document.

silverpill@mitra.social on 01 Oct 2024 15:33 next collapse

@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

mikedev@fediversity.site on 01 Oct 2024 20:04 collapse

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 @trwnh@mastodon.social 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@mitra.social on 02 Oct 2024 13:53 collapse

@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@mitra.social on 02 Oct 2024 13:58 collapse

@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

trwnh@mastodon.social on 02 Oct 2024 14:23 collapse

@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@mitra.social on 02 Oct 2024 16:51 collapse

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

trwnh@mastodon.social on 02 Oct 2024 16:54 collapse

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