There’s nothing stopping a malicious user from doing that right now. Be aware that anyone who wants can already see your votes.

We already depend on trusting instances for a lot of what’s going on here, I don’t see why we shouldn’t be able to defederate untrusted ones.

1. Currently, any admin can modify any local user activity, can’t they?
2. Not really, your local instance may still hold the vote data for validation. And therefore could be ported and resigned.
3. Don’t see the problem.
4. Today, each instance decides whomever they want federation with. The ones who decide the criteria should be the same ones who decide whom the instance federates with.

Your first comment expands on both privacy and security. There is no privacy without some type of security.

Now to answer your questions: Yes and yes. Users from c/all were downvoting posts from a small community I’m a part of because they don’t agree with. I couldn’t see the posts from small communities that are important to me because of that. Now we have the possibility to sort by “scaled”, which fixes that. Sometimes there are discussions that are very relevant as to who is voting for what. But that discussion has nothing to do with privacy, which was your first point and went unacknowledged on your second comment.

Not only admins can see the votes, but anyone on Fediverse (except regular Lemmy users) can see them.

Security through obscurity is prone to failure when it is used by itself. If people want their votes to actually be private then another method of securing their privacy should be created.

User choice would be best indeed. The problem is that currently the votes are public but hidden from Lemmy regular users. Anonymize votes seems to be such a big problem the devs don’t even want to consider it.

I completely agree with the idea of more accountability. We are real people in acting public right here, we should be constantly aware that our actions have consequences. If you don’t want your pseudonym associated with a vote, don’t do it. It’s kinda like the opposite of 4chan, where instand of anonymous controversial content on top, here we have human-curated content being pushed up.

What it the instance signs the activity? Then it propagates to others instances after local validation. That way only local admins would have access to voting data. Malicious instances could still be defederated/blocked/have votes disregarded.

Works with CUDA and RDPing on a 2x2 monitor grid?

You said you used river, so I’ve checked their wiki https://github.com/riverwm/river/wiki/Recommended-Software#output-configuration

Maybe you can add your tool there as well.

Looks similar to https://git.sr.ht/~leon_plickat/wlopm/

It would be best to try every single one separately, otherwise you’ll have dozens of programs that do the exact same thing, like file explorers.

That said, with Fedora you can list available desktop environments using the default package manager, dnf. In a terminal use the dnf group list command to list all available desktop environments:

dnf group list --available *desktop

Install the required desktop environment using the dnf install command. Ensure to prefix with the @ sign, for example:

dnf install @kde-desktop-environment

After trying the DE, you can remove it with:

dnf remove @kde-desktop-environment

I had success with iodine, it’s slow but it worked.

Sorry to burst your bubble, but there already exists a proposal to make communities work more like a cloud.

It’s just a matter of time before Lemmy and Kbin implement this.

Yes, the proposal is something like Nostr, but the clients can also relay data on request if they’re online. A little more decentralized.

Worth mentioning that the idea is not to make Lemmy abandon ActivityPub, but to allow further decentralisation.

There wouldn’t be a need to keep all data like a blockchain to query all data since most sort by hot/recent. Something like Gossipsub would suffice for most users.

But whenever an user queries for old or specific data, the request could be directed to a relay that archives and sorts all data.

Not a completely different protocol when the changes are additions to the existing one. The same protocol would still exist and be supported.

P2p enabled instances would have the option to reverse the communication flow, so besides the servers having to send updates to subscribed servers, the subscribers would have the option to ping peers/servers for updates.

This would help with sync issues when a post is made and the changes are not propagated to all subscribers.

Roaming IP wouldn’t be really a problem with libp2p, you can have a permanent address with a peer id.

Most people don’t come here to see archival stuff, so it wouldn’t be so bad if the p2p network cached ephemerally (time limit or a size limit). Old content could still be reached on servers designed to cache old stuff.

Events could be cached on the p2p network, so the phone only pings its peers for new content (mind the existing servers would be peers on the network).