These are Lemmy instances with a “Sign Up” link which present you with a form to fill out to register. Then after you fill out the form and supply information like email address to the server, they respond with “registration closed”:
- lemmy.escapebigtech.info (dead node now, but got instant reg. closed msg when they were alive)
- expats.zone
- hackertalks.com
- lemmie.be
- lemmy.killtime.online
- lemmy.kmoneyserver.com
- lemmy.sarcasticdeveloper.com
- level-up.zone
- zoo.splitlinux.org
I suppose it’s unlikely to be malice considering how many there are. It’s likely a case of shitty software design. There should be a toggle for open/closed registration and when it’s closed there should be no “Sign Up” button in the first place. And if someone visits the registration URL despite a lack of Sign Up link, it should show a reg. closed announcement.
Guess it’s worth mentioning there are some instances that accept your application for review (often with interview field) but then either let your application rot (“pending application” forever) or they silently reject it (you only discover non-acceptance when you make a login attempt and either get “login failed” or even more rudely it just re-renders the login form with no msg). These nodes fall into the selective non-acceptance category:
- lemmy.cringecollective.io
- lemmy.techtriage.guru
- lemmy.hacktheplanet.be (pretends to send confirmation email then silently neglects to)
- links.esq.social
- dubvee.org
To be fair, I use a disposable email address which could be a reason the 5 above to reject my application. And if they did give a reason via email, I would not see it. Not sure if that’s happening but that’s also a case of bad software. That is, when a login attempt is made, the server could present the rationale for refusal. Another software defect would be failing to instantly reject an unacceptible email address.
I could understand that if you had been granted an account you’d successfully logged into, and then started receiving login refusal afterwards; but to have not actually had an account yet makes it pretty obvious when you try to login and fail that the application has not been accepted. Whether that’s an explicit refusal, or just an idle queue that’s being ignored, doesn’t really make a difference. If the instance admins wanted to talk about it, they’d have emailed you; or published some means of contacting them outside lemmy.
I wouldn’t expect to receive the reason for refusing the application via any other means than the email I’d provided in that application. That’s the entire purpose of providing an email; so you could be contacted when/if there are updates to your applications status.
If you’re going to provide false contact info, you can’t be all that surprised when you don’t receive communication(s).
to have not actually had an account yet makes it pretty obvious when you try to login and fail that the application has not been accepted.
That would be a blunt non-transparent/non-specific message to send. It’s not obvious /why/ the app was denied.
If the instance admins wanted to talk about it, they’d have emailed you; or published some means of contacting them outside lemmy.
Lemmy software is designed to make email address disclosure optional. An admin can make it mandatory, but Lemmy’s design should cater for the email-free option regardless of how an admin toggles that setting.
I wouldn’t expect to receive the reason for refusing the application via any other means than the email I’d provided in that application.
I get that. People are accustomed to relying on email. But this is not an excuse for software deficiencies.
That’s the entire purpose of providing an email; so you could be contacted when/if there are updates to your applications status.
That can be accomplished without email. Email is a convenience at best. Some users have decided email is an inconvenience and do not use it. And Lemmy supports that – partially.
Let’s be clear about who the software is expected to serve. The comms feature of giving feedback to users without an email account is not to directly serve the end user. Software should serve its user (the Lemmy admin in this case). A Lemmy admin does not want to take the time to express themselves on their decision only to have their msg blackholed. They don’t necessarily know that an email address is disposable. The end user benefits by extension, but it’s about creating software that serves the direct user of the s/w. If you’re an admin who makes email optional, you might still want to be able to get a msg to a user.
The core purpose of the Lemmy platform is communication. So relying on out-of-band tech is kind of embarrassing. An in-band msg has the advantage that the admin has more control (e.g. they can edit a msg later and they can know whether the msg has been fetched).
The only sensible concession I would see to make is that there are a hell of a lot more important things for Lemmy devs to work on because the software has a lot of relatively serious defects. I’m talking about how great software would be coded, but extra diligent handling of denials should have a low triage in the big scheme of the state of where Lemmy is right now.
