How to subscribe to a thread?

Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.

So here is an alternative: FEP-f06f: Object observers.

Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.

I am once again astounded by how unreasonably effective FEP 1b12 is at federating content completely.

On NodeBB I have a list of "popular" topics, which is mainly populated based on number of posts within a given time period. For most content from Mastodon-based servers, this supplies a decent signal of a given topic's popularity. The more people you follow, the more effective it is, but overall it's pretty shit at getting you the whole conversation.

Enter 1b12, Lemmy's preferred federation method. Follow a community actor and you start receiving everything that happens in that community. Replies, likes, the whole lot.

It also absolutely dominates my popular feed. It's all Lemmy stuff now because the Mastodon stuff literally can't compare.

Albeit the SNR is a tad lower, so give and take...

Is there an #FEP which covers adding the attributedTo property to collections?

#ActivityPub

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.

@trwnh@mastodon.social, today at fediforum I met with @jesseplusplus@mastodon.social who is working on a federated photo sharing app with strong focus on privacy.

We discussed FEP 7888 and how that might address her concerns re: resolving ghost replies

So unlike me, who would implement context owner sending of Add mostly to comply with the FEP, she'll actually be wanting to start off with that part!

@thisismissem@hachyderm.io in a post yesterday brought back the idea that better post controls could be achieved if the reply were sent to the target only, and the target then forwards it if applicable.

It reminded me of @trwnh@mastodon.social's https://w3id.org/fep/7888, which attempts to govern a similar flow where a reply is sent to the context owner (instead of inReplyTo, which I think was Em's intent), and the context owner (and/or originating server) federates out an Add if approved.

Which got me thinking about whether that federated server could actually send out a Remove too!

Let's say a reply is made but later on, a mod decides that it is to be deleted. A Remove would be a way to signal to other instances that the content actually be removed/deleted!

We could even take it one step further; servers will always exist who don't adhere to the philosophy of the context owner approving replies. If they federate their own replies out, the context owner could actually proactively send a Reject and limit the spread of those replies...