Search

@return2ozma This ships don’t work and are being decommissioned. Most of the time they are in a port being repaired. You can’t blame them wanting a connection to the world.

https://www.propublica.org/article/how-navy-spent-billions-littoral-combat-ship

You might prefer smaller instances; … This part of it is clearly not a bug, however you put it. It is a difference of preference.

My personal preference happens to align with fedi principles. Don’t let that consistency fool you. I’m not advocating for what’s best for me. I am saying the list should be ordered in a way that’s healthy for the fedi based on the federation’s purpose and mission.

Showing the biggest communities on top may be your personal preference, but that is not healthy for the federation.

I myself am on an instance that’s almost identical in size to yours.

FYI, aussie.zone is centralized on a US tech giant (Cloudflare) and thus contrary to fedi principles. Though it’s not the worst manifestation of Cloudflare because they have whitelisted Tor. But there are still many other demographics of people likely being excluded from aussie.zone.

I do not see the value in smaller communities being prioritised when they each cover the same topic. If there’s [email protected] with 10,000 subscribers and [email protected] with me and my twelve mates, lemmy.world is the one the app should show people first. It wouldn’t matter to me whether that 10,000 is on lemmy.world or midwest.social, it makes sense to show users the place they’re likely to have the most interaction.

That is not healthy for the federation. That imbalance is a problem that Lemmy has failed to control. The disproportionately large communities need no promotion. Too many people know about them already. They should either not be listed at all or be pushed lower on the list. It’s an extra slap in the face and injustice that these are exclusive Cloudflare instances that are getting prioritized. These are instances without self-control on their growth and power.

It’s not instance-related at all.

It is instance related. If you search for Android on other instances you will get different lists. Users on infosec.pub have subscribed to every Android community in existence which makes the manifestation of the problem unique to infosec.pub. The [email protected] community is also federated to infosec.pub by way of my subscription. It is true to fedi principles of inclusion and decentralization, unlike those that get listed on the top. So it’s an unhealthy sequence.

It could even be one user account that caused this. The activism.openworlds.info Mastodon instance was getting hammered with traffic. After investigation, they discovered that one user was following a shit ton of other accounts. All those follows were responsible for the admins struggling to cope with all the traffic. That instance eventually went under because it could not cope with the bandwidth demands.

This belongs in discussion around lemmy-ui, the various Lemmy apps & alternative front-ends, or in Lemmy itself with what gets returned by its search API.

The software part of the problem is specifically in the stock Lemmy web client. The bug tracker for the Lemmy web client is jailed in MS Github’s walled garden, hence why it was originally posted in [email protected]. There may be a configuration element to this, which is why it’s posted in this infosec.pub community. If there is an inactive account with all these android subscriptions, that can be remedied on the instance.

order should be descending order of size.

If bigger is better, why are you here instead of Facebook and Twitter? Fedi principles and philosophy have completely escaped you. In the fedi, we consider power imbalances, privacy abuses, and exclusivity resulting from centralization to not only worsen UX but to be an injustice. Encouraging disproportionate growth in the fedi is to advocate the destruction of what brings us here.

Unfortunately they seem not to be active on Lemmy anymore. The other admin, @[email protected] is though, so maybe they have some idea?

You might have to @[email protected] if there isn't notes on why listed. Sometimes instances get compromised and flood bad stuff. Maybe the instance can be enabled if there's no other reason to keep it disabled.

@[email protected] Would you share any of the following, I'm just curious:

• what's rough user count
• what's average instance CPU, memory, bandwidth use
• database and file storage
• cost
• time commitment
• Colo, business, residential

[edited this report to update with correct info] My workflow is I click on create post, post the URL of the media, upload a small image of the logo, add the body text with links to the conference information and meda.

The issue is that when I add the image, the URL of the image gets put into the URL field of the create post page.

Previously the URL in the create post page could be directly to the YouTube video. For example https://infosec.pub/post/3334303 worked fine.

even when: @jerry and @shellSharks are working on the servers. and I have nothing but praise for them.

I also think there should be some (small) group of people able to help & assist with the task of maintenance and support of the backend.

(and i don't mean getting root access to anyone's hardware, especially not without vetting)

and I would also think it would be a good idea to have some (open) scenario / manual / strategies for different standard actions, preferably with a script to also fix the issue.

(just some ideas running through my brain)

First of all thanks for the very detailed response. I have a few questions.

1. Like you said, why not use public key cryptography? Why is it not well supported for web-apps?

2. Why not use something like Diffie-Hellman algorithm to share the password? Signal protocol uses ECDHE so I am assuming that it's safe against mitm which the base Diffie-Hellman is vulnerable to (I might be wrong. I couldn't find if it waa vulnerable or not).

The 2FA process itself - both initial setup and use with an OTP provider - has worked consistently for me so far. The instruction in the interface is misleading and I'm not the only one who locked himself out as a result. The Mastodon devs merged my pull request to clarify the instruction (including my mistake of saying "oauth" instead of "otpauth") astonishingly quickly.

If I may be constructively critical, we should expect to provide provide at least some minimal evidence to justify claims such as one that something doesn't work, even if only as a link to discussion or evidence. This expectation increases when it's accompanied by advice or instruction, especially when such advice is counter to advice which is generally accepted as "good".

As @[email protected] mentions, a more serious problem of password reset via email disabling 2FA offers a workaround for now in at least some cases.

[._.]

Everything was good for a while, but the 500s are back here on Fedia, particularly on index pages :(

@jerry

@[email protected]

@lefractal @infosecpub if you never got the confirmation email you won't be able to login I would message @jerry about confirming your account. He is going to need your username on @infosecpub to fix it.

@Spellbind0127 @infosecpub
Hey, I got the same issue when I try to login using a brand new account. Using username or email yields the same "spinner of death" :(
I also never got a confirmation email, but I don't remember the UI telling me there was any error with my account.
I also tried using another browser without crap-blocker, and even without any vpn connection.
Is this temporary overload or is there something I can do to fix this ?

@shellsharks @infosecpub testing a reply

@aemaeth @infosecpub

I haven't done any testing with pixelfed yet. Creating an account is on my list of things to do though. Testing would likely come sometime after that.

@shellsharks @infosecpub @ivory @radiant @jknlsn
Have you done any testing with PixelFed yet? I think it should have a very similar interaction...