Thanks! Codeberg.org gives my browser problems, but I was able to shallow clone that over Tor using git.

My first hack was to add a --socks4a parameter to all the curl calls to force it over Tor.

It did not work out of the box. I could see that it sources config.sh. The example file shows API keys. The instances_list.json file shows {"error":{"message":"Invalid Authorization header."}}, which implies that I need an API key. If I simply run this:

curl --socks4a 127.0.0.1:9050 -o "${filename}" 'https://fediseer.com/api/v1/all_instances'

there is no problem. I suppose you have hard-coded an API key to do operations that submit data, which is then used for getting data as well. Anyway, the script works for checking a single instance.

I wrote a script that uses Cloudflare’s ASNs to grab all its IP ranges. Then the script checks without even connecting to the target just by resolving the IP and checking if it matches CF’s range. It’s still just a messy workaround. It’s really something that should be in the fediseer dataset.

A larger server would mean you’re more of a desirable target, but a small server (which “ideally” every server would be) would still have those same vulnerabilities.

Two servers can have the same vulns but it’s not just a vuln-counting exercise. They don’t have the same threat model. There is no need to control for a vuln that will not be exploited, or where exploitation has negligable effect. A small instance that supports a dozen users running client X need not control for a vuln that only impacts users of client Y (to give a simplified example).

Small servers have more options for controlling for vulns. They don’t have to worry about a countermeasure breaking some obscure client as they don’t have a broadly diverse number of software configs connecting. By contrast, a large node is limited in how it can control for vulns due to having to support many different client configs from a diverse range of networks.

If there are thousands of users, then all possible varieties of client configurations are in play. And also the stakes are also higher (1000s of outraged ppl). Along with higher stakes is also the fact that there is a much greater chance of a sophisticated user getting pissed off at the administration and attacking. LW likely has countless inside adversaries.

There is even a greater chance of accidents being exploited on large nodes. E.g. the lemmy bug where a random user arbitrarily got admin privs spontaneously due to a glitch when the server was simultaneously accessed by many users. These sort of bugs don’t manifest on a node of a dozen users.

Small nodes can trivially stay current on versions. Whereas large nodes need to plan their migrations. The window of lag time gives an opportunity for attack.

And servers need to be cost effective. Not everyone can afford to run a server out of the good of their heart, and those that are able to do that are already preselected to be fairly wealthy.

A residential broadband connection and a cheap throwaway PC will do. A small instance accumulates ~30gb/year. I suppose it depends on one’s own perspective whether that calls for “wealth” but where I am PCs are dumped on curbs that can handle the workload.

but rather to ensure the instance is cushioned against unforeseen events and cost increases.

100% availability would be nice, but there are trade-offs. Concentrated power on LW is a bad trade. Defeats the problem activitypub was meant to address.

Instances that can be expected to last beyond the short-term to medium-term should be backed by a non-profit organization with commitments to users to remove key man risk.

Sure, stability is good, so long as the instance does not sell souls to Cloudflare or grow disproportionately big.

Even under the scenario of full data portability, switching instances creates confusion (particularly for casual users who just want to create an account and not worry about whether it will still exist in a year) and breaks @ mention links, so safeguards to reduce the risk of instance failure outweigh the downsides of reduced decentralization.

Data portability is not at odds with decentralization. It’s the other way around. A good degree of data portability promotes decentralization precisely because disaster can be mitigated when small intances fall.

Or are you calling centralization the “safeguard”? What a horrible trade to make. The right answer is better software, not centralization.

Given that the software is being developed by literal communists and isn’t in the hands of the Lemmy.world operators, I don’t think limited centralization is likely to lead to user base exploitation or a particularly strong network effect.

Look at the numbers. Network effect is in full force. Lemmy.world (Cloudflare centralized) is huge, an order of magnitude bigger than the 2nd biggest (sh.itjust.works IIRC, also Cloudflare). Dev.lemmy.ml was the biggest originally, and also Cloudflared to enable unhealthy growth. The devs wisdom improved and they scaled back deliberately. Now lemmy.ml is no longer centralized on Cloudflare (which was quite an embarrassment for founders of an activitypub implementation) and much smaller than LW (though still more than 2 std deviations bigger than the mean).

If an LW admin does not like what you write, you lose reach to a large portion of the fedi because of 1 person’s influence. Fuck convenience; esp. when convenience comes with Reddit-like power abuses.

Ultimately instances with more users are better able to collect donations and reduce per-user monthly costs,

Everyone has their reasons for defending centralization. For you it is cost savings, apparently. Money wins, unless the tech is done well.

(edit) Small instances are cheaper to secure because they are less prone to targeting. The bigger an instance gets, the more it costs per user for infosec.

it also wouldn’t be good to have them spread out evenly across 1,000 instances.

It would be good, but not for the bottom line. Facebook has mastered the bottom line indeed.

Without a mechanism for user data to be completely transferred between instances (including post and voting history), an instance shutting down is a terrible experience for new users that could encourage them to return to a commercial social media network and must thus be avoided at all costs.

It’s a problem for sure. Lemmy devs are pro-data portability, but they give it a low priority. They hope that someone will build a bot that ports data so long as it does not require Lemmy server code to be written. IOW, they (Nutomic specifically) calls for a hack job. He posts pseudocode here: https://lemmy.ml/post/31128657/19022698

Indeed avoiding Cloudflare is the ethical thing to do. But I just wanted to point out that sh.itjust.works is a Cloudflare node, so I suggest choosing a different fedi instance.

Bingo. It’s people going where the people are. Which is the reason people often give for migrating to lemmy.world and mastodon.social.

I’m just planning to serve my instance with a onion address.

Did you ever go through with that? Cognitive dissonance would be triggered for me because lemy.lol is in Cloudflare’s walled-garden which is the world’s biggest adversary of the Tor community.

I think I have only encountered 1 onion lemmy instance so far.

You have to make and maintain one account for every interest you have?

Giving you wrote that 2 yrs ago, I guess by now you must know that you don’t need an acct on every node that carries communities of interest. Nothing about a balanced fedi forces you to maintain many accounts.

Nonetheless, it’s a good idea to have several accounts anyway, particularly for privacy. And also to not be blinded by fedi politics that creates bubbles. Maintaining multiple accounts is a burden but it’s only because we don’t have good client apps. A good app can make multiple accts seamless.

think instances should be bland an irrelevant.

Yikes. What a horrible way to organise communities. Two of the best known thematic instances are down right now: mander.xyz and slrpnk.net. People are feeling the loss precisely because of the loss of well organised communities.

I agree w/your underlying thesis – that having more thematic instances would improve the fedi. But it’s a bit of a false dichotomy to frame centralization as “not the problem”. Centralization is a problem of both power concentration and also fault tolerance (lemmy.world goes down and we lose half the fedi).

Having more thematic instances helps curb centralization. It’s part of the solution. We still need other mechanisms to create balance.

So if any instance becomes evil people just have to seamlessly move away.

The bad assumption here is that everyone knows about the wrongdoings of an admin. When the power is abused, the masses don’t know to move. The mastodon.social admins arbitrarily block whoever expresses a viewpoint they oppose. The thousands of users who that power affects are mostly unaware. The rest are too lazy to move.

The mastodon.social instance /is/ evil. Yet people have not moved away.

It’s still down for me. Just times out. So I have no idea what you propose.

Anyway, I don’t imagine how a workaround would be possible. The dataset is missing the data. If I have to scrape for the data myself, it defeats the point of a public dataset. I could write in my code a Cloudflare check, but that doesn’t help anyone else using the fediseer dataset.

Would you mind describing it? That forge is apparently down.

It ends silent downvotes and forces transparency. Then they are inclined to reply and say “the mod action was justified for X… Y… Z.” Then the mod supporters upvote that, which in turn shows us what feedback and votes are sensible and which can be disregarded (e.g. when the reaction is unrelated to enforcing rules).

Makes no sense to support downvotes on the basis that upvotes don’t change. Lack of upvotes does not have the silencing effect that downvotes has, or the misleading sum of votes that conceals upvotes.

The current state of the ambiguous sidebar is cause for people to call the rules shit.

Having well articulated rules is not generally for the haters. It’s to properly guide those with goodwill – at least in this case, where it’s an unenforcable rule.

Of course the best fix is to move to a well-configured node.

I don’t see any solution for this in a public internet forum.

A good fix is to move this community to one of these instances:

• libretechni.ca
• crazypeople.online
• beehaw.org

because downvotes are rightfully disabled on those nodes.

“Justified” is far more subjective than “breaks a written rule”. People are indeed voting with their emotion (as opposed to assessing whether a rule was broken which is much less subjective).

“It is justified that that asshole who disagrees with me got censored”.

I agree with your whole thesis here, however unpopular. The voting is so arbitrary it’s useless.

The sidebar is unclear:

“Do not downvote posts if you think they deserved it. Use the comment votes (see below) for that.”

The side-bar still today fails to answer @sudo@programming.dev’s question. It does not specify how the voting should be used.

In principle, the interesting question is whether a mod action is consistent with the rules. Folks often post here because a mod took action against a rule-abiding post. Yet they get down-voted anyway because of distaste for the user who is being oppressed (thus the down-voter simply agrees w/oppressing opposing viewpoints).

Even IF the side-bar were well written to cover this, the crowd doesn’t give a shit. It’s plainly evident that voters vote to push their emotion. Too many undisciplined brains. So really, the only sensible fix is this.

The tldr app is in Debian official repos so I installed it with apt tools. From there, it failed me:

$ tldr wg
Downloading tldr pages to ~/.local/share/tldr
tldr: HttpExceptionRequest Request {
  host                 = "tldr.sh"
  port                 = 443
  secure               = True
  requestHeaders       = []
  path                 = "/assets/tldr.zip"
  queryString          = ""
  method               = "GET"
  proxy                = Nothing
  rawBody              = False
  redirectCount        = 10
  responseTimeout      = ResponseTimeoutDefault
  requestVersion       = HTTP/1.1
  proxySecureMode      = ProxySecureWithConnect
}
 (ConnectionFailure Network.Socket.getAddrInfo (called with preferred socket type/protocol: AddrInfo {addrFlags = [], addrFamily = AF_UNSPEC, addrSocketType = Stream, addrProtocol = 0, addrAddress = 0.0.0.0:0, addrCanonName = Nothing}, host name: Just "tldr.sh", service name: Just "443"): does not exist (Temporary failure in name resolution))

Looks like it needs cloud access. My gear only works on Tor, so then I tried it this way:

$ torsocks tldr wg
No tldr entry for wg
$ torsocks tldr wget
No tldr entry for wget
$ torsocks tldr find
No tldr entry for find
$ torsocks tldr rsync
No tldr entry for rsync
$ torsocks tldr -u
Downloading tldr pages to ~/.local/share/tldr
tldr: Data.Binary.Get.runGet at position 4: Did not find end of central directory signature
CallStack (from HasCallStack):
  error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in binary-0.8.8.0:Data.Binary.Get

Also checked for kmdr but that’s not in the official debian repos, which I try to stick to. I appreciate the tips though.

Sadly, not enough people will realise Matrix is a shitty alternative.

SimpleX is Cloudflare-free. Matrix is not.

It’s important to realise that programming.dev is centralised in Cloudflare, a US-based gatekeeper who is antithetical to fedi principles. When someone looks for an alternative to #Reddit, I imagine they don’t want yet another tech giant. They are looking for a decentralised place that values balance of power.

So I suggest directing people to !emacs@lemmy.sdf.org instead.