What if the lack of comments were because comments weren't proportionally representative?
Someone sees a discussion that interests them, so they see what the top comments are. But if the Hive Mind(tm) has spoken (even if just by awarding the top two or three comments to the same viewpoint), will they engage, or will they go somewhere else?
Remove the Hive Mind, and maybe you'll get more engagement?
I was thinking of it as a drop-in replacement for "hot" just so that it doesn't require any changes on the UI to implement. I'm a bit rusty with UI development, lol. The frontends wouldn't have to add a new button, and the Lemmy API wouldn't need to add a new sort type. That said, maybe that sort of thing is easy to do?
As far as it would work, Thiele's elimination rules is computed roughly as follows (I'm assuming that only upvotes are counted; I haven't considered yet if the process works if disapprovals count as a vote of "-1" or how the process could remain scalable if an abstention counts as a vote of "0.5":
begin with the list of posts, list of users, and list of votes
# initial weighting, takes O(E)
for each post:
for each vote on the post:
lookup the user that voted on the post
based on the number of votes the user has given, determine how much the user would be made "unhappy" if the current post was removed
# the basic idea here is that if the user didn't vote for a post, then they won't care if its removed
# if the user did vote for a post, but also voted for 100 others, then they probably won't care if one gets removed as long as 99 remain
# if the user did vote for a post, but only voted for 2 or 1 others, then they'll care more if this one gets removed
# if this is the only post the user voted for, then they'll care a lot if it gets removed
# LiquidFeedback uses a formula of "1/r", where r is the total number of votes the user has given
# as posts get removed, the votes get removed too, so surviving votes get more weight
# for the sake of efficiency, I'll probably use a formula like "if r > 20 then 0 else 1/r" so that users only start to contribute weight to posts once they only have 20 approvals left. Replace 20 with a constant of your choice
add the user's resistance to the post being removed to the post
# initial heap construction, takes O(C)
construct a min-heap of the posts based on the sum of the users' resistances to the post being removed
# iterative removal of posts
while posts remain in the heap: # O(C)
remove the first post in the heap - this has the least resistance to this post being marked 'last' in the current set # O(logC)
yield the removed post
for each vote for the removed post: # in total, O(E) - every vote is iterated once, across the entire lifetime of the heap
lookup the user that voted on the post
compute this user's resistance to this post being removed
remove this vote from the user
based on the number of remaining votes the user has given, compute the user's resistance to the next post being removed
compute how much the user's resistance to their next post being removed increased (let this be "resistance increase")
if "resistance increase" is nonzero (based on my formula, this will happen whenever they have less than 20 votes remaining, but not if they have more than 20 votes remaining):
for each vote for a different post by this user:
increase the post resistance to removal by "resistance increase"
perform an "increase_key" operation on the min-heap for this post # this will be O(logC)
# worst-case, each user will perform 20 + 19 + 18 + ... "increase_key" operations -
# they only begin once there are 20 votes remaining
# when they have 20 votes remaining, they have 20 increase_key's to do
# when they have 19 votes remaining, they have 19 increase_key's to do
# etc.
# because this is a constant, it doesn't contribute to the time complexity analysis.
# so each user performs at worst a constant number of O(logC) operations
# so the overall time complexity of the "increase_key" operations is O(VlogC)
For this algorithm, the yield the removed post statement will return the sorted posts in reverse order. So worst to best. You could also interpret that statement as "Give the post a rank in the final sorting of count(posts) - (i++)".
Thiele says that process can be used to elect a committee of size N by stopping your removal when N votes remain. But because it's a "house monotonic" process (electoral speak for "increasing the size of the committee by one and re-running an election is guaranteed not to cost any existing members their seat), I figure it could be repurposed to produce a ranking as well - the top one item is "best one", the top two items are the best two, the top three are the best three, etc.
To make the above process work for approvals that decay over time, we'd just treat a decayed approval as a partial approval. I still have some work to do on how exactly to integrate partial approvals into the "resistance to removing each post" calculations without ruining my time complexity. But basically it's a proportional score voting election instead of proportional approval.
This is exactly the info I'm looking for, thanks! I knew there'd have to be some kind of scheduled task to recompute the rankings (IIRC the lemmy docs say ~10 minutes for recomputing ranks), I just wasn't sure where it was.
The change that would require the least effort to implement my voting system (whether the lemmy maintainers would accept the change notwithstanding) would be to target the schedule task, and introduce a server-wide configuration option that would allow admins to pick whether they're using Block Approval (what we have now) or Proportional Approval (what I'm introducing) based algorithms for their server's "hot" algorithm. No API or frontent changes required. Then, work towards community mods being able to set that on a per-community basis.
Something for me to experiment with, anyway.
I don't think it would work for my specific algorithm, unfortunately. To compute PAV, I need access to the "raw votes" of each individual user.
PAV doesn't need to know the identity of the user behind each upvote, but it does need to be able to correlate which upvotes originated from the same user so that once a user is determined to be "satisfied" by having a comment they upvoted given a high rank, all of their other upvotes need to be deweighted for the remainder of the process to "make room" for other users' opinions.
I checked the Lemmy API docs, and while that information is available at /api/v4/post/like/list and /api/v4/comment/like/list, so I could have a frontend that scraped every comment and then every like of every comment in a community (ignoring how inefficient that would be), but both of those endpoints are tagged as "Admin-only".
Plus, even if I could do that, to compute the rankings my process does need the upvotes of every comment in a post (or every post in a community) before it knows which one is on top, which seems too much to put on a client.
Then the conversation would be dominated by whoever has the most time to make posts, which isn't what I'm going for. I'd rather have a method that satisfies Proportional Representation.
Maybe when you're closer to adding Friendica I'll return with a similar pitch, but for Friendica accounts.
Technically speaking, from what I've read, Identity+ and Friendica both support SAML as an SSO protocol, but based on the limited documentation of the latter and lack of documentation on the former (you really have to ctrl-F that page to find SAML referenced) it seems a potentially janky integration where users would lose control of usernames/nicknames, and knowing the government (despite me literally advocating for them lol) they'd probably generate a horrible username like a UUID.
But maybe that just means there needs to be a better Friendica SSO authentication addon.
Regardless, the general vibe of a platform like Friendica definitely feels more aligned with my proposal of "one account, one human user" than something like Lemmy anyways, as several other commentators have suggested.
True. And Lemmy is even designed for a mix of bot and human accounts, given the "account is a bot" flag that can be set in account settings.
The question is, how do we ensure the accounts that are not flagged as a bot, are indeed not bots?
Yeah, the vibe I'm getting from the general feedback to this post seems to be "interesting idea, but for something other than lemmy." For the Lemmy platform in particular, my proposal seems a solution in search of a problem.
I do think it’s an interesting concept and would be an interesting experiment on a new instance.
I’m just not sure that’s feasible on this platform. Lemmy is really designed to keep people anonymous.
I was imagining that this kind of verification would be part of account registration. So it wouldn't be like "you have two classes of user account, one has a checkmark or something", but instead "you have one class of user account, and can't log in unless you verify you're a unique human".
Which, yeah, would probably work better on a new instance, so people can choose "this is the server where having an account means I am a real person" vs "this is the server where I stay anonymous to everyone, including site admins". An instance that mixed 'unverified users' and 'verified users' would probably just be hassle with no benefit.
If it was done on a designated instance, I don't think anything would, at a technical level, prevent it from being done on any particular platform (eg. lemmy vs mastodon vs pixelfed). But I'll concede that the design of Lemmy may make it the wrong platform for my proposal.
In a way it feels like twitters verified feature, and that makes me wonder if it would work in mastodon
I agree that it's similar to Twitter's verified feature.
But from what I've seen of Mastodon, Mastodon's verification feature doesn't work like Twitter's - Mastodon just lets you put links on your profile and verify the link, but that's just you proving to Mastodon that you control the domain name. Sort of like getting a TLS certificate from Let's Encrypt, where you just prove to LE that you control the domain.
It's not like a 'verified' status on the account as a whole.
So the way I imagine it, it'd work for Mastodon, but not by creating two classes of users - it'd just work by ensuring all users on the instance as a whole are verified.
What other platforms are Fedecan considering adding, and what sort of timeline do you guys have for your 'next expansion'? I want to say there was a page that listed PeerTube, Friendica, Mastodon, etc. as potential 'future expansions', but I can't find it anymore.
Maybe one of those could be the subject of an experiment like this (and if the experiment were successful, Fedecan could use it as a place for the community to hold votes on the direction of Fedecan, if you ever wanted to formally democratize any particular decision).
Bots haven’t really been a huge issue yet, but it’ll be a Fediverse wide one so we need a solution that would scale like that.
The current standard for Fediverse content moderation seems to be for each instance to manage its own content moderation policies, and each instance defederates / block those few instances that are particularly repulsive to them.
Taking content moderation as precedent for the issue of bot mitigation, the onus of mitigating bots will be on the instance admins, where known bot farms just get defederated.
I’m also not keen on any sort of pii link to our users, even if it’s Canada post holding that data.
A fair concern, but IMO needing something like this is inevitable. Maybe I'm just "early", but I don't think I'm wrong.
If the concern is ensuring each user can't be linked to a specific set of PII, then an anonymous credential system like U-Prove could cryptographically guarantee that each account belongs to a unique real person, without revealing which real person it is.
(Many anonymous credential protocols, including U-Prove, come with 'single-spend' mechanisms that can be used to ensure one user can't get two accounts.)
Basically, with anonymous credentials, you'd end up with two sets of data: One with whatever PII-linkable info Canada Post gave to Fedecan, and another containing the actual user accounts. But (provided users used Tor to prevent IP address correlation) it'd be cryptographically impossible to link the any of the first to any of the second.
They would just come in via other federated instances
True, but it would at least build a reputation of "1 lemmy.ca user = 1 real person".
If we’re not selling user eyeballs or data, do we care if a user maps to a real person?
I'd say yes, we should care.
I'm not on lemmy to chat with bots; I want to know that when someone responds to me, that they're a real person, and that if five people respond to me, they're five different real people, even if I have no way of knowing who those real people are.
I also want people who see my posts to know there's an IRL person behind them and that my account isn't just one sockpuppet of many, though I don't want them to know my IRL identity.
If I wanted to chat with bots I'd just generate an artificial group chat with a few ChatGPT or DeepSeek agents, lol.
But at the same time, this winner-take-all national seats mechanism, if triggered, will guarantee the loss of checks and balances, and accountability to a single party. This is a catastrophic disaster for any democracy, and cannot be accepted. Once again, this 50% score threshold as described has no legitimate basis – unlike in proportional representation electoral systems.
a higher goal, “the government represents the interests of as many voters as possible”
Coming back to this point, I’m not sure if this electoral system effectively addresses this. However, having strong conflict of interest, ethics codes, and anti-corruption laws might be a more effective avenue than via the electoral system. The folks at Democracy Watch are quite keen on this topic.
If the essence of democracy is to have everyone having a seat at the table, a representative democracy must still maintain this principle. A winner-take-all system, even if partial, is contrary to the principles of democracy.
What's the point of having a seat at a table if a group of 51% form a coalition that has no incentive to listen to you? Sure, your voice is heard, but what use is that if you're not obeyed?
I think this is the main philosophical difference between my system and the "current approach" to electoral reform.
The 'standard representative democratic tradition' tasks elected representatives with coming up with policy to consider all constituents' needs, but my 'gut feeling' on the subject is that the sorts of people capable of becoming elected representatives (ie. politicians) are the least capable of all of us at engaging in good-faith deliberation with the 'other side'. I'm also a bit skeptical of the value of codes of ethics, but maybe I'm just a pessimist from absorbing US political news.
So instead of "election -> representatives deliberate -> policy decided", I take the alternate approach of "representatives campaign -> election -> policy decided", on the basis that with the right electoral system, a "big tent" party could be incentivized to come up with a broadly popular party before the election, and then just be tasked with implementing it after.
Link posts from thetyee.ca appear to be previewing the Cloudflare captcha challenge "Attention Required! | Cloudflare" prompt instead of actual content.
What it looks like (two examples - this seems to be a consistent problem for thetyee):
(from https://lemmy.ca/post/39053782)
(from https://lemmy.ca/post/39058782)
What it should look like (a different post):
My guess is that the rich link preview is generated in Lemmy's backend, and Cloudflare thinks that the IP address of lemmy.ca's host is full of bots.
No educated guess on the solution, though, but I'd guess that other Lemmy admins have seen sort of thing too.