Theoretically, it shouldn’t matter.

In the ideal case every connected server should host a full and complete copy of the data from the originating server (as xkdrxodrixkr@feddit.org says, that’s B)

Reality is a bit different, but not enough to warrant always picking B. Just share whichever you’d like, but B is the most right.

> We have the potential to create something far more human and revolutionary than any of the ad-based mainstream platforms.

Right on! That’s the refrain I hear a lot from people who discover ActivityPub and then build software for it.

Building something out of principle is a wonderful approach. I hope someday were in a position so that you don’t have to sacrifice principles to make money.

Yes. When the reply is posted to C, it is sent to A. A then sends as:Announce to C, as well as any other communities that follow it.

B seems to be irrelevant here.

Hi! We should chat.

NodeBB also does this, and currently still does. A category (group actor) can follow another category (also a group actor).

It essentially is synchronization of categories using 1b12.

Proof of concept does work but it needs reworking in some ways. The largest issue is that Lemmy itself doesn’t understand when a group actor tries to follow a community.

Tell me about it! There are some very cool people (i.e. thisismissem@hachyderm.io) working on content classification and tagging so that the burden of filtering out this kind of content isn’t borne by server admins directly.

snoopy@jlai.lu personally, since I create AP enabled software I am on the side of votes being public data. We already have enough issues with votes being out of sync with each other. Mixing in private voting is just asking for trouble.

Emoji reactions are neat, although niche to those softwares that utilise it. They allow for greater expression which is nice. They’re useless for deriving value (for ranking purposes) unless you assign value to them.

Does anyone remember way before Google had image recognition technology, the time they built a game that paired up random people on the internet, showed them each an image, and waited for them to both guess the same keyword?

It was gamified human powered taxonomy for meaningless internet points and it was hilarious (at the time.)

rglullis@communick.news A little bit, yes! There was a recent thread in the community I posted to where a discussion about the rather lacklustre search of various software took place.

Very interesting article! I have immense respect for jerry@infosec.exchange, he was one of the first people I found on the fediverse, and it’s no wonder why, he’s revered quite highly by others as being a generous and kind admin.

I do want to point out one thing, and that is that Mastodon has some design decisions that make it rather resource and storage intensive.

There are oodles of lighter software out there, some with even more features than Mastodon, and some with less. For example, snac.bsd.cafe (https://snac.bsd.cafe/) runs on Snac, which is fast as hell.

I am going to guess that a not insignificant portion of Jerry’s bill is caching assets. Mastodon likes to save everything it encounters, videos, images, avatars, everything… forever (though I imagine this is customisable). Most likely the assets are viewed a handful of times in one day and never seen again… but you’ll pay to store it forever!

Thanks! It’s something that I personally feel is more performant and future proof for other important things like private discussions (which Mastodon also doesn’t support natively yet — mention spamming doesn’t count.)

Sure, check out my post about it here:

https://community.nodebb.org/topic/18844/backfilling-conversations-two-major-approaches

There are steps being taken in the right direction.

Lemmy and lots of other software use a fediverse extension called 1b12 to keep everything in sync.

In a nutshell it means Lemmy communities can follow other communities, and they keep each other in sync. The same applies for other types of communities, like PieFed communities, Mbin magazines, NodeBB categories, etc.

Mastodon doesn’t have a concept of community or categories, so they don’t support this kind of synchronization.

There’s NodeBB if you want a forum/BBS style UX for the threadiverse!

I suppose you’re right in a way. The context owner is not supposed to be set by someone other than the context owner. It’s a fallback mechanism intended for better compatibility with Mastodon.

When a group is addressed and it is one of the local NodeBB categories, it will assume control

If it is another group that it knows about but isn’t same origin to the author, then no category is assumed.

silverpill@mitra.social yes, it should. Mentioning the category means it will be addressed and NodeBB will slot the received content in the first group object it finds.

Yes, NodeBB does travel up inReplyTo. I’m not sure why it isn’t working for some Lemmy topics currently.

projectmoon@forum.agnos.is it’ll work better once cross-posting is built into NodeBB I think :smile:

> One weakness I have noticed in NodeBB’s current federation is that posts which are in reply to a topic (e.g. a Lemmy comment) show up as individual threads until (or if) the root post of that topic shows up in the local NodeBB.

No, Lemmy does not implement either strategy, they rely on 1b12 only.

If NodeBB is receiving parts of a topic that don’t resolve up to the root-level post that might be something we can fix. I’ll try to take a look at it.

silverpill@mitra.social said: > If the OP is the single source of truth, they can moderate the entire conversation (represented by context collection: Streams). If not, then each reply is independent and authors moderate only the direct replies (represented by replies collections: GoToSocial).

That is a good point. The approaches are broadly compatible when top-down moderation by the context owner is not assumed.

In a moderated scenario, crawling the reply tree would not be useful unless paired with some sort of “is member of” validation with the context owner… at which point the served collection would be more performant.

It could be useful for discovery by the context owner itself though.

For what it’s worth your blog does show up fine in NodeBB as well. Perhaps you are missing the @context property and so Mastodon is refusing to parse it?