Damn, how’d you get your reviewers to write your entire paper for you?

Yeah that seems about right.

I don’t know how the versioning works for the Android versions here…

Android has the same versions as desktop here, which is why there is no differentiation. The main chunk of firefox is platform independent (and even used in thunderbird too).

So any firefox android app and fork thereof needs that version 131.0.3+ too (unless it is esr which is 128 currently).

173? What happened to firefox versions? We just started the 130s

The offline version is on izzyondroid.
The design is worse, yes.

I don’t think it matters much because most of the time you only see the autofill thing, not the app.
When you do go to the app, it is to select between multiple credentials, which is still a split second action.

On mobile I have my 2fa in a different more convenient app (aegis), though k2a does allow to copy 2fa codes

It doesn’t.
Both DX and K2A-O open a local keepass file.
They are capable of reloading the file when it is changed, and can be set to immediately write out changes to the file.
Then you take whichever file sync tool you like and sync it with all other devices using it. As long as the sync tool can sync files in your internal storage, it will work.

I use syncthing, with a dedicated keepass folder containing only the database file. Then I simply add all my devices to the share and it’ll sync any changes to all other devices. I also have version history enabled for the share.

Keepass2Android Offline also works very well. It has a somewhat different feature set compared to DX.
I found it to be more stable at remaining permanentl unlocked, and DX dropped the 3rd domain level for password matching on either websites or apps, I don’t remember.
On the other hand DX works better for adding new credentials or making changes. Since I usually do that on desktop it doesn’t matter much for me.

They were doing the same on other repos for months.
Both their npm module and android client.
On android they tried to get people to add their own fdroid repo because the official fdroid has not had updates for 3 months due to the license changes.

Edit: Looking at it now compared to 4 days ago, they apparently got frdoid to remove bitwarden entirely from the repo. To me this looks like they are sweeping it under the rug, hiding the change pretending it has always been on their own repo they control.

Next time they try this the mobile app won’t run into issues, the exact issues that this time raised awareness and caused the outcry on the desktop app, which similarly is present in repos with license requirements.

If they were giving up on their plan, wouldn’t they “fix” the android license issue and resume updating fdroid, instead of burning all bridges and dropping it from the repo entirely, still pushing their own ustom repo? Where is the npm license revert?

Also important to note is that they are creating the same license problems in other places.

They broke f-droid builds 3 months ago and try to navigate users to their own repo now. Their own repo ofc not applying foss requirements, because the android app is no longer foss as of 3 months ago. Now the f-droid version is slowly going out of date, which creates a nice security risk for no reason other than their greed.

Apparently they also closed-sourced their “convenient” npm Bitwarden module 2 months ago, using some hard to follow reference to a license file. Previously it was marked GPL3.

It means previous versions remain open, but ownership trumps any license restrictions.
They don’t license the code to themselves, they just have it. And if they want to close source it they can.

GPLv3 and copyleft only work to protect against non-owners doing that. CLA means a project is not strongly open source, the company doing that CLA can rugpull at any time.

The fact a project even has a CLA should be extremely suspect, because this is exactly what you would use that for. To ensure you can harvest contributions and none of those contributers will stand in your way when you later burn the bridges and enshittify.

I never claimed calling us omnivores was incorrect. Our meat digestion ability sucks too, compared to most carnivores.

Just fine is pushing it, we are capable but not particularly good.
We need specific plant parts grown on purpose to be consumable (fruit, nuts, …), or we need cooking.
There is a good number of plant stuff like grass, certain bark, and most parts of medium sized plants which a lot of animals can consume but we cannot.
If you go out and eat random plants you will die you won’t be able to digest almost any of that.

I would argue there are loosely two levels of plant digestion ability above ours.
The first being what most mamals have, which allows to consume leafs and most small and medium plants minus the thicker stalks. My example would be deer.
Then there are ruminants who can digest grass more efficiently and tend to deal with stalks better, main difference being more things being worth digesting vs. just being digestible. Classic example is cows.

Spreads Dirac Sea with malicious intent

That isn’t really going out of your way, it is the base mode of how the fediverse works. Looking at something on a different instance.
Plenty of people just use mbin and see this, without any action at all.
The point is that as it stands right now, there are already basically no restrictions. The only thing perhaps missing is the knowledge that you can simply copy paste a link into fedia or another mbin instance to view upvotes.

You can open an issue on mbin about it, to restore a semblance of restriction. But currently as it stands, all restrictions are about as fallen as they could be.

You can ofc argue that we shouldn’t open another equivalent hole in lemmys webui and api, so that you can in the future remove the ability from mbin.

I would in turn argue that this system has always been egregious, and that in the same sense as banning encryption you never hit those you want to hit using incomplete restrictions. Regular users are led to believe their votes are private, while the worst dataminers or trolls will always have their instances to query all of that info.
And how could you inform people that their votes are public without at the same time telling them how to get access to that info?

If mbin removes the info, you will get another fediverse software showing it. You will get fediverse activity pub log info pages, specific vote info pages, it will never end.
Has reddit ever managed to kill the 200ᵗʰ removeddit clone?

Please instead put your effort into changing the way lemmy federates, the only way to fix this is to make vote details private, between only a select few instances. An mbin dev in the other thread mentioned PeerTube as an example implementation where you could remove vote details like that.

This would solve some of the problems. If only 2 instances know about the votes, post instance and sublemmy instance, you can reasonably expect to get most instances to never release that info. It would allow either the sublemmy or post instance to manipulate around in the votes, but most manipulation would be detectable by the respective other instance.

It would open the door however to manipulating around with internal posts made from the instance in a sublemmy on the instance. And it would allow the post instance to drop votes selectively, though I think that is possible currently all the same.

Votes being sent to both the sublemmy and the post instance simultaneously would make manipulation a lot harder. And for cases like internal posts, you could add another involved “judge instance” that receives the vote details directly from source, and is merely there to confirm the total. Instances that hand out non-independent “judge instances” could be labeled as untrustworthy in the lemmy community.

So you end up with a list of instances per post that votes are reported to, to which you add the post instance, sublemmy instance, judge instance, and maybe some more.

In terms of implementation, I think the activitypub protocol needs an origin for votes, right? I would say an instance can just report the votes coming from a stock of obviously fake accounts, like “masked_upvote_1” to _999999 … and “masked_downvote_1” to _XYZ.
About the votes, I am not sure. It could be done as a lemmy-internal feature where lemmy instances and other instances knowing of the lemmy protocol send the info to all the relevant instances, while any votes from external instances only arrive at I guess the post instance and that then forwards it on to all other instances. This way the checking doesn’t work for software unaware of that lemmy specific vote implementation, but everything is still compatible.

You could then even for those lemmy-external votes add an interface on the judge instance, that would confirm via pm if your vote has arrived.

Do you think this could work?

In my case I would like them to be private, but currently they are not. I don’t think it is good to try to hinder the visibility into a fundamentally transparent system.

I don’t see a technical way to make votes private either, that doesn’t prevent bad actor instances abusing the vote system. As an admin of an instance I could just add 5-10 votes to all of my interactions whenever I feel like it, and noone would be able to tell it didn’t come from legitimate users on my instance. The accounts of vote origin are needed as proof, hence moderators on lemmy having access to them.

Do you perhaps have any idea how this could be accomplished?

That’s a pretty reasonable compromise, and probably explains my confusion.
Why didn’t you do the same for remote upvotes?

Then maybe it is still around on some instances?
Either way, it is only a matter of time for another fediverse software to show downvotes, or someone to spin up a vote info page which gets its information via undisclosed legitimate fediverse instances so you cannot defederate them.

There is a “Reduces” tab on mbin, which shows downvotes

The US wasn’t even mentioned in the post, implying this as generic problems which is not the case.

Your world does not correspond to reality given that mbin already shows individual votes.

Head over to your comment on fedia.io and see who voted on your own comment.

Do you want to only vote on instances that defederate all mbin instances, and commit to keep doing so in the future?