It depends on the method of PR you're using, but if people value "one constituency, one representative" (or "equally distributed Parliamentary power among constituencies") the idea of having a pool of representatives that aren't accountable to any specific constituency could be a downside.

Eg. if you use a "closed list party-list proportional representation" where the parties get to pick who gets the 'proportional seats' from their own ranks, then some MPs are accountable only to their own parties; they don't have constituents that can threaten their jobs.

But that's easily addressed by just using a different kind of PR. RCV-PR uses ranked ballots where voters support individual candidates in a multimember district, and dual member proportional has its own apportionment method that gives every constituency two representatives accountable to the voters of that constituency.

So as far as weaknesses go, that one is an easily mitigated one.

In case the majority is the extremist party, PR allows a sort of damage control.

I'm not sure I follow. If an extremist has an absolute majority, ie. 51% of seats, then they have control?

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.

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.

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.

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?

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.

Thanks for the response! You're one of the first people to give feedback on it, so there's a few points I tried to make in the original post that, in retrospect, might have benefitted from some rewording.

The only benefit I see in this scoring system, is that it allows voters to express their degree of support with their candidate, rather than just their ordering of support as found in ranking systems.

Basically, the system you’ve proposed adds additional incentive to gathering “a majority support”, and no additional benefit beyond that.

I'll start with responding to this statement, since this is I think where the key of the argument for my system is, and then respond to everything else in-order.

The core of my argument was supposed to be that:

1. Score Voting on its own incentivizes exceeding majority support within the electorate of a single Score Voting election, and
2. Given that Score (or cardinal systems in general) have those incentives, turning the Parliamentary election into a single nationwide Score election gives that nationwide election the same incentives of Score Voting

But evidently I need to rework my presentation.

The big idea

The basic idea behind Score (and Cardinal systems in general) is that multiple competing candidates can have the support of concurrent majorities.

Eg. Candidate A can have 70% support, and Candidate B can also have 70% support at the same time, because whatever the voters gave to Candidate A, the ballots do not prevent them from giving the same support to Candidate B. This distribution could come from:

• 70% of the electorate strongly approve of A and B,
• 30% approve of A only; 30% of B only; 40% approve of both A and B,
• 100% gave A and B a 7/10,
• or some other combination.

So the incentive to exceed a majority is that once you have a majority, sure, you're now eligible for the winner-take-all mechanism, but you're not necessarily the only one eligible for it. So a candidate can believe they have 60% support, but knowing a competitor can also have 60% support at the same time, they are forced to broaden their campaign to 70% support, or 80% support, or as high as they can make it go until the next vote gained is two votes lost.

Whereas in FPTP, voters can support only one choice (meaning voters' support is exclusive, so majority = win), and in ranked systems, the general philosophy is to support your first choice exclusively (again, majority = win) unless the first choice would be a wasted vote, in which case they move on to their second choice.

I think my argument may have been more clear had I described the system with Approval Voting, which allows voters to approve of multiple candidates but not to describe how much they prefer one approved candidate to another, and then said in a footnote that Score Voting has the added bonus of 'degrees of support', but that this bonus isn't required to create the overall incentive structure I describe.

The short of it is that your electoral system looks very similar to MMP. I’m not saying that’s good or bad, just is.

I somewhat agree.

They look similar in terms of what seats exist - both systems have 2-member constituencies, with one member assigned by the results of a local ballots, and another member assigned by the results of all ballots nationwide.

But my system differs in terms of how the seats are assigned, and what ballots the voters are given: In MMP, voters get a first-preference ballot, with mine, voters get a Score ballot, and the national seats are 'winner-take-all' rather than proportional.

I think we (MMP and I) both converged on the "each constituency gets two MPs" because we're both responding to the same perceived demand, in Canada at least, for equal distribution of political power among constituencies in Parliament.

51 of 100 of seats in said parliament are needed to form government

This isn’t quite right. What’s necessary to form government is to command the confidence of the (lower) house, in order to maintain “supply” (which is funding to the government). So only budget bills need a majority.

I'll concede that my statement did simplify reality. I also recognize there may be some situations where the opposition can team up with parties in a governing coalition to get something passed that one of the 'main coalition partners' opposes - I think there were a few cases where that happened since the last election, but can't recall which.

But I think the general idea, that you need a majority in order to get anything done, and no more than a majority to get something done, still stands - confidence of the HoC, and bills in general, are both measured by majority votes. So a group that has a majority of seats effectively wields the full power of the HoC, as long as they can keep just that majority.

And I think that this continues to be true even in PR.

What doesn’t make sense to me: what’s the relevance of this 50% barrier for national seats? There is no basis in legitimacy.

TBH I picked it arbitrarily. It could be 40%, or 60%. That barrier came from balancing the following:

• If the most popular party has a very low score, say 25%, then the nation has some genuine and serious divisions, and it would be better to make the MPs deliberate to form policy than to give one party all the power
• Without a winner-take-all segment there's no incentive for a party or coalition to exceed 50% support, so if a popular party has a very high score, say 75%, then it should win a winner-take-all segment, or else nobody will bother trying to achieve that high score.
• The above two points mean that somewhere between say 25% and 75% the winner-take-all segment has to be "phased in".
• Having all of the winner-take-all seats 'kick in' at 50% was easier to describe than trying to define a 'graduated schedule' where the most popular party gets X seats at 40%, 2X seats at 50%, 3X seats at 60%, etc., and trying to describe how to balance 'equal constituency weight' with all of that.

If a national party receives a 50% score, this does not mean that 50% of the voters agree with said party. For example, if 60% of voters score a national party 4/9, and 40% score 6/9, would that mean most voters don’t agree with the party, yet the party would be eligible to hold 50% of the electorate? Apologies if the math is off, but I’m trying to demonstrate a scenario where most don’t actually like the party, but a “small” minority overrides the majority.

(emphasis on edits mine for personal preference in distinguishing score-votes from rank-votes)

I'll agree that a national party with those votes is nobody's first choice. But what what those scores do represent is a party that is broadly tolerable or barely passing. Which is a better approval rating than I think most governments get.

I think this is more of a philosophical question of, which of the following is better:

1. A party that 60% of the country gives 8/9 to, and 40% gives 0/9 to, or
2. A party that 60% of the country gives 4/9 to, and 40% gives 6/9?

The math of those two options end up both giving equal averages of 48/90.

As a side note, I think the scale of 0 to 9 from my original proposal may not be the most intuitive scale - votes out of 10 would probably have been better - but just about any scale works. The simplest form of Score Voting, Approval Voting, just has a scale of "Agree / Disagree". Like a FPTP ballot, except you can approve of more candidates than one. So having an average support of 51% with Approval ballots maps pretty neatly to "A majority approves"; then Score effectively gives voters the ability to give partial approvals.

The only benefit I see in this scoring system, is that it allows voters to express their degree of support with their candidate, rather than just their ordering of support as found in ranking systems.

Basically, the system you’ve proposed adds additional incentive to gathering “a majority support”, and no additional benefit beyond that.

Score lets voters support multiple candidates simultaneously, so multiple candidates can have a majority at the same time, so once two or more candidates achieve concurrent majorities, they have to then compete for the largest majority.

Ignoring my 'winner-take-all eligibility threshold', this means that "majority" no longer means "that threshold where you win", it just means "that threshold where some of your supporters probably also supported the other guy too."

Which makes gathering "a majority support" the beginning of the competition, rather than the end.

I hope what I've said about this makes sense and is more clear than in my original post - 'voters support candidates simultaneously' is the keystone of my entire system; if you use a non-Cardinal voting system for the winner-take-all element then you don't get any of "exceed-a-majority" incentive that I describe.

(continued in nested reply)

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.

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

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.

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.

Lemmy mainline could also skip rich link preview generation if it returns a non-2xx status. Have a few retries if link preview generation fails, and omit the preview entirely if retries are exhausted. I think the Attention Required! | Cloudflare prompt is associated with a 403 Forbidden status code.

And also generate some logs of what addresses are being refused, so the Lemmy admins can reach out to the content owners and get their servers unblocked, maybe.

Huh. TIL!

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?

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.