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

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

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

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

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.

@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

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