I recently read a complaint about the opposite. Someone deleted their Proton account and their handle was made available 1 year later. They were rightfully angry because the next user would potentially start receiving mail from things like the original user’s bank. The new user could perform password resets on accounts where the original user had not yet changed the email address on file.

Thanks! It’s rarely used so trying to find back a post that used it would be hard. Knowing the terminology (spoiler) was half the battle.

Why?

1. It’s a big database. It would be a poor design to replicate a db of all links in every single client.
2. Synchronization of the db would not be cheap. When Bob says link X has anti-feature Y, that information must then be shared with 10s of thousands of other users.

Perhaps you have a more absolute idea of centralized. With Mastodon votes, they are centralized on each node but of course overall that’s actually decentralized. My bad. I probably shouldn’t have said centralized. I meant more centralized than a client-by-client basis. It’d be early to pin those details down at this point other than to say it’s crazy for each client to maintain a separate copy of that DB.

And how would guarantee the integrity of the ones holding the metrics?

The server is much better equipped than the user for that. The guarantee would be the same guarantee that you have with Mastodon votes. Good enough to be fit for purpose. For any given Mastodon poll everyone sees a subset of votes. But that’s fine. Perfection is not critical here. You wouldn’t want it to decide a general election, but you don’t need that level of integrity.

A lot less effort than having to deal with the different “features” that each website admin decides to run on their own.

That doesn’t make sense. Either one person upgrades their Lemmy server, or thousands of people have to install, configure, and maintain a dozen different browser plugins ported to a variety of different browsers (nearly impossible enough to call impossible). Then every Lemmy client also has to replicate that complexity.

I mean, does archive.org get away with it, though?

They get blocked by some sites, and some sites have pro-actively opt-out. archive.org respects the opt-outs. AFAICT, archive.org gets away w/archiving non-optout cases where their bot was permitted.

And do I really have to spell out how Google gets away with caching stuff?

You might need to explain why 12ft.io gets away with sharing google’s cache, as Lemmy could theoretically operate the same way.

I’m extremely skeptical fair use could be twisted to our defense in this particular case.

When you say “twisted”, do you mean commentary is not a standard accepted and well-known fair use scenario?

You don’t know what a logical fallacy is. Bob and Alice can disagree about whether the pizza tastes good or bad. There’s no fallacy there, just subjective disagreement.

The browser (more appropriately named: client) indeed needs some of the logic here, but it cannot do the full job I’ve outlined. The metrics need to be centralized. And specifically when you say browser, this imposes an inefficient amount of effort & expertise on the end-user. A dedicated client can make it easy on the user. But it’s an incomplete solution nonetheless.

You just identified the fallacy yourself.

You’re going to have to name this fallacy you keep talking about because so far you’re not making sense.

Sometimes a paywalled source is the first to report on something. Calling that link a bad link is nonsense.

One man’s bad link is another man’s good link. It’s nonsense to prescribe for everyone one definition of “bad”. What’s bad weather? Rain? I love rain. Stop trying to speak for everyone and impose your idea of “bad” on people.

Many people don’t know all the websites to redirect things through without that, so calling their contribution “bad” just because they posted that link isn’t the greatest.

So because someone might not know their link is bad, it ceases to be bad? Nonsense.

It’s not even like it’s that big an issue, because usually someone else comes along that provides an alt link in the replies,

(emphasis mine) Usually that does not happen.

so saying that this is a social failure is also ridiculous, because both were provided between two people.

This based on the false premise that usually bad links are supplemented by an alternate from someone else.

Also, the notion that you or anyone else is socially filtering non-misinformation news sources from the rest of us, because you don’t see the value in it, or cannot figure out how to bypass the paywall yourself, isn’t all that great either.

(emphasis mine) Every user can define an enshitified site how they want. If you like paywalls, why not have your user-side config give you a personalized favorable presentation of such links?

Just like Greenpeace paves the way for smaller activist groups that can’t stand up to challenges, archive.org would serve in the same way. When archive.org (with ALA backing) wins a case, that’s a win for everyone who would do the same. Lemmy would obviously stay behind on the path archive.org paves and not try to lead.

A link is not a bad link for going to the source. You’ve misunderstood the post and also failed to identify a logical fallacy (even had your understanding been correct).

Whether the link goes to the source or not is irrelevant. I’m calling it a bad link if it goes to a place that’s either enshitified and/or where the content is unreachable (source or not). This is more elaborate than what you’re used to. There’s more than a dozen variables that can make a link bad. Sometimes the mirror is worse than the source (e.g. archive*ph, which is a Cloudflared mirror site).

One man’s bug is another man’s feature. The hair-splitting you attempt here really serves no useful purpose. I’m calling it a bug because input data is overly trusted and inadequately processed. It could be framed as a bug or an enhancement and either way shouldn’t impact the treatment (beyond triage/priority).

if a tester posted something like this as a bug instead of a change request, it would get thrown right into the trash bin

Yikes. Your suggestion that it should impact whether it’s treated at all is absurd. Bug reports and enhancements are generally filed in the same place regardless. If you’re tossing out bugs/enhancements because you think they are mis-marked, instead of fixing the marking, I wouldn’t want you working on any project that affects me or that I work on. That’s terrible. Shame on you.

Side note, do the hash tags do anything on lemmy, or are they just posted here for emphasis?

They have search index relevance in the fediverse. People outside of Lemmy will find the Lemmy post if they search those hashtags (which are ignored by Lemmy itself).

It would need some analysis by legal experts. But consider that archive.org gets away with it. Although archive.org has an opt-out mechanism. So perhaps each Lemmy instance should have an opt-out mechanism, which should push a CAPTCHA in perhaps one of few good uses for CAPTCHAs. Then if Quora wants to opt-out, they have to visit every Lemmy instance, complete the opt-out form, and solve the CAPTCHA. Muahaha!

Note as well how 12ft.io works: it serves you Google’s cache of a site (which is actually what the search index uses). How did Google get a right to keep those caches?

There’s also the #fairUse doctrine. You can quote a work if your commenting on it. Which is what we do in the threadiverse. Though not always – so perhaps the caching should be restricted to threads that have comments.

When you say “some users don’t trigger it”, that’s probably a feature. It’s important to know if a user is federated with the server the msg is posted to in order for them to get the notification.

Indeed we can always write a markup hyperlink and put the users address in it, but that’s not the point. That would not ensure that they get the notification. It’s the automatic generation of that link that tells us whether the user was recognized.

I believe we 1st have a documentation bug since the docs do not cover this. And functionality-wise, we should be able to see a list of who is mentioned for the purpose of notifications.

I don’t do MS #Github (#deleteGithub). Or MS (anything) for that matter. I am 100% #GAFAM and #Cloudflare-free. I will generally report issues to #Debian’s bug tracker but that’s only an option for pkgs that are in Debian’s official repos. #Lemmy is not – which in itself is a concern.

Debian requires packages to reach a certain quality standard. When a pkg becomes official Debian it suggests the package has enough popularity & quality to be taken seriously. Debian is quite popular¹ so Lemmy should try to put itself on the map. Until then I’ll have to file my bugs under the LemmyBug hashtag.

1: https://has-no.solutions/objects/5891cf49-163d-491e-900a-6b5af92fa9a0

I’m calling this a #LemmyBug. When an address is copy-pasted into a msg, you have no indication of whether the other account was properly recognized and that they will get a notification. When I view source, it just shows the body of the msg not the JSON record.

I’m using the stock web client of slrpnk.net (whatever version that is), and when I type @[email protected] … oh, wow, that worked. Strange. In the cases that failed me, I copy-pasted the user’s address. So apparently it must be typed out manually to trigger auto-complete. I see that the client just makes it a markdown hyperlink to your profile. That’s useful, but what’s more important is that the user get a notification. When i copy-paste the address (e.g. @[email protected]) there’s nothing to signal to me that the user was recognized and that they will actually be populated in the “mentions” field of the JSON record.

I’m skeptical. That mention of me in your msg is an URL with the mailto: scheme, which has the effect of launching an email client that tries to treat a Lemmy address as an email address.

That is way beyond acceptable use

Each server would have its own acceptable use policy. Also consider the social detriment of Cloudflare nodes. We could even say @[email protected] has a moral /duty/ to overwork the Cloudflare nodes :)

@[email protected]: thanks for pointing out lestat. That’s one of the very few services of this kind to be responsible enough to red-flag the Cloudflare nodes. I hope @[email protected] follows that example; though it could still be improved on.

It’s misleading for any tor-blocking Cloudflare node to have a 100% availability stat just because by design it deliberately breaks availability to a number of users in an arbitrarily discriminatory fashion. https://lemmy-status.org/ and https://lemmy.fediverse.observer/stats do a bit of a disservice by not omitting or flagging #Cloudflare nodes.

Indeed. IIUC, OP said 33 reqs/min is a ceiling and tunable on a per-target basis.

If the target is a Cloudflare instance, you could perhaps even do 300 reqs/min without even being noticed.

Exactly… makes no sense that that post would trigger a lot of people. We can only guess because down votes don’t come with an explanation.

What I’ve noticed in the nation-specific communities is there’s usually a strong amount of national pride. Denmark in particular but I notice the same in Netherlands communities. If a post can be taken to be negative or embarrassing to the region, criticism tends to be unwanted and down votes are likely.

In the case at hand the post was factually accurate and not really provocative. Since people wouldn’t likely get too emotionally hot-headed about ATMs, it seems unlikely that a large number of people would be so emotionally triggered. Probably just one person with many accounts.

It could be legit.

It might be interesting for #Lemmy to add a smart algo that checks whether a rapid sequence of down votes occurs in a short span of time and see if the set of accounts used for the down voting shows a voting pattern with other posts. Or even without timing analysis, voting patterns alone might reveal accounts used for timeline tampering particularly if the same IP address is used.