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.

A smart attack would be coupled with a clear message. Have the malware clobber them with anti-evil messages and just like that you have a sound free speech defense.

Consider florida, where if you are caught with shrooms that are wet, freshly picked, they cannot convict you for carrying contraband because you do not necessarily know what you picked.

Laws are often based on intent. In some cases, penalties vary depending on intent. It would be an unacceptably brutally harsh law to judge someone under a presumption of harmful intent for something they might have no awareness of.

QR codes can have icons on them. Certainly if I created such a t-shirt, I would put some cool looking icon in the center of it. Someone being dragged through the system might argue “i did not know that qr code was real… i just liked the cat in the middle of it”.

“Malice” implies intent. Accidents are not malicious. Neglect in the worst case. So certainly any charges could not be based on malice.

Not sure but I think QR codes that hold wi-fi creds would more likely be automatically processed by phones. Seems like an adequate attack surface. Maybe dodgy creds could overflow or do some kind of DB attack. Or even legit creds could lead someone to connect to a malicious hot-spot captive portal that the attacker carries.

Thanks for the tip. It seems to work but I have to say it’s a rough UX because the UI is really meant for a graphical browser. I could not even paste my UID and PW in to login.

For the same reason, I suppose you would love text adventure games like Hitchhiker’s Guide to the Galaxy, where you have to come up with your action, as opposed to getting visual aids which come like a loaded question, steering you and somewhat robbing you of control.

indeed… #NeonModemOverdrive failed for me too.

So, how did you do post to lemmy.ml? Did you use cURL? If so, I would love to see the sample code.