FEP-7888 and the Add activity

julian

@[email protected] 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 @[email protected]'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...

bh4 tech

@julian Would like to suggest two improvements in the service-worker of NodeBB before version 4(GA) is released-

Web-push notification support. You open sourced the firebase plugin but that doesn't seem to be working.
2)Offline caching of (one-to-one)chats.

May be I can also make a PR if you can guide me from where to start.

julian

@bh4-tech please start a new topic for this unrelated discussion, thanks!

infinite love ⴳ

@julian @thisismissem if you just check the replies/context collection directly then it doesn’t matter which other posts might exist but haven’t been added.

if you as a client are aware of a reply/threaded-post outside of those collections, then it would be best to consider it “singly linked” — navigating from the post to the parent/thread is possible, but then the post would effectively not be visible from those views.

Mike Macgirvin 🖥️

Last year, I moved conversations into Collections identified by the context element, and we only accepted Add/Remove activities for collections from Collection->attributedTo. All submissions were made to them and only to them.

We previously sent replies only to the thread originator - a concept for restricted access conversations I came up with about the same time the Diaspora folks did. We kept it for a number of years even though Mastodon didn't support it, but moving conversation threads into a simple collection management operation not only makes sense, it bloody works brilliantly and co-exists with microblogging. It also co-exists with FEP-7888.

Jupiter Rowland

@julian @Emelia

It's also fair to mention that this has been the standard mode of operation for everything @Mike Macgirvin

️ has ever created until this year, starting in 2010 with Mistpark which is Friendica today. Friendica still behaves like this, Hubzilla still behaves like this, and (streams) behaved like this until the move to Collections in 2023. Forte is the only exception, it started with Collections right away which, on the outside, don't feel much different.

After all, they're more or less Facebook alternatives. And not the Twitter clone as which the Fediverse in its entirety is being perceived nowadays.

The advantage of this is that everyone who participates in a conversation generally always receives all replies. Not only those that mention them.

From a Mastodon point of view, this concept may appear either revolutionary or entirely unimaginable. But it has been around for 14 years.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Friendica #Hubzilla #Streams #(streams) #Forte #Conversations

silverpill

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

infinite love ⴳ

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

infinite love ⴳ

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

infinite love ⴳ

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

silverpill

@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

infinite love ⴳ

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

:PUA: Shlee fucked around and

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