@mikedev @trwnh @thisismissem @julian As far as I can tell, Containers not simply co-exist with FEP-7888 but fully satisfy its requirements.

@silverpill @thisismissem @mikedev @julian yeah, the only point of difference i recall when reading about comversation containers was a bit about using target.attributedTo (FEP-400e) instead, which i would personally discourage in favor of context.attributedTo so that there is only one source of truth. aside from that, FEP-7888 certainly covers this implementation in at least spirit if not fully in letter -- the core of it is as simple as "please use `context` for tracking the conversation".

@silverpill @thisismissem @mikedev @julian the rest of the stuff only really applies if the context happens to be 1) resolvable, 2) a Collection, and 3) owned by somebody. which i would recommend doing because it just makes sense, certainly more useful than an opaque URI.

the bits about sending to only the context owner is also only really a courtesy, for cases where you want to recognize their authority and it really matters to you whether you're in the collection or not.

@silverpill @thisismissem @mikedev @julian i think the most robust thing to do in an open world system is to treat properties like `inReplyTo` and `context` not as facts but as claims. if you want to verify those claims, resolve the collection and check for inclusion.

i'd like to make that flow more efficient in the future with something like https://w3id.org/fep/0391 -- use an Add activity as a stamp of inclusion.

@trwnh @thisismissem @mikedev @julian

>In a constrained conversation, the target->id and the context are identical.

So target.attributedTo and context.attributedTo would be identical too

@silverpill @thisismissem @mikedev @julian i understand that the producer can produce documents where the two are the same, but the very nature of their being two properties means that there is the possibility that they will not match.

I would be happy to consolidate, but I think the chances of some large percentage of the fediverse choking badly on an array for the context element are pretty high. Same reason I don't use an array in an actor 'url' field. It's  a few years since I tried this, but 2/3 of the fediverse projects at the time couldn't deal with it and nobody bothered to fix it for years because "Mastodon doesn't do this, so you must be doing something wrong."

Anyway, I'm retired from the fediverse shit-show now. Y'all can do what you want. But please implement comment control. It isn't a "feature" - it's basic online security (except for some freespeech folks who still think everybody with an opinion or a dick has some God-given right to shove it in your face).

The fediverse you save might be your own.

bsmall2 likes julian's status

@mikedev Yeah, the way current fedi handles "conversations" is very poor: they basically don't.

it actually seems quite technically simple to handle them, but it does come at the cost of "efficiency" and "scale": realize we are building web browsers, and browse those collections directly. maybe cache those collections, maybe use Add/Remove as a rudimentary state sync or mechanism (or at least cache invalidation). but the basic idea is not to blindly make up whatever you *think* is in them.

@julian @thisismissem @trwnh makes sense as well for “followers only”… if you post a post with abuse and include someone..

It *could* reach the somebody and all of their followers as well boosted via their server (with controls. Opens the abuse vector slightly.