@regalia
In either Lemmy algorithm, only communities that Server Y knows about can be featured on the front page of Server Y, right? Which as I said, is also going to benefit larger communities, as they're more likely to have members on more servers, and will therefore be featured on more front pages.
@regalia
> I believe “active” sort has comments bump put an entire post
So a new comment in a thread bumps the OP to the front of the queue?
> The “hot” algo is slightly more complicated that factors in votes
Ah, right. I hadn't considered that. "Votes" in Lemmy are essentially the same as "Favourites" in Mastodon, but I think the Masto devs made an intentional choice not to increase visibility of posts based on number of Favourites.
@regalia
> I recommend actually looking at what it looks like on the site, it’s extremely different then how it looks on mastodon
Yes, I'm familiar. I've been following Lemmy development for several years, as part of research for fediverse.party. That's the background to my comments about the algorithm determining what appears on a Lemmy front page.
If you're proposing that there's a more complicated algorithm at work, what do you think it is?
@regalia
> the algo for active/hot favor large communties, so smaller ones tend not to show up on the front page
I presume it's the same as what determines which posts appear on the front page of a Mastodon server; chronological order of posts. That would favour the larger communities, since people post there more often.
The other limiting factor, I presume, is a Lemmy server only knows about the communities its accounts are members of. Larger communities will have members on more servers.
@deadsuperhero
> development of a Go-based backend implementation, Dendrite
Also Rust-based homeserver implementations like Construct and Conduit. Both of which are usable, although missing a few nice-to-have added features. Eg Conduit is still working on;
"E2EE emoji comparison over federation (E2EE chat works)... Outgoing read receipts, typing, presence over federation"
@smileyhead
> But noone figured out how to prevent that in federated systems
You've basically got a choice been a centralised service where metadata can be limited but E2EE is mostly pointless (you have to trust the service operators' E2EE deployment), or a decentralised network where E2EE is reliable, but it's harder to limit metadata.
Which one is best depends on the situation/ threat model.
@timbuck2themoon
Matrix apps are far from perfect, but its dev community at least care about improving HX and it shows. In my experience, the XMPP dev community (with a few notable exceptions like the ModernXMPP folks) insist on seeing their HX fails as features not bugs. They expect people to stop expecting 21st century chat apps, and embrace 1990s retro.
I've used XMPP since then (I'm still strypey@jabber.org), and all I can say is, good luck with that.