eriner_

Ah, that's what you're referring to. As I mentioned in a comment on the previous thread (which I now see you commented on two days ago), we didn't want to require phone numbers for verification and went the email-only route instead. Unfortunately there was a not-insignificant amount of abuse from temporary email addresses. Because they are temporary and throwaway accounts and we have no way of reliably contacting the humans behind those accounts, our best option was to prevent players from using accounts with those throwaway domains.

As you stated in your other comment, it sounds like you got your money's worth. Accounts can still be registered with non-throwaway emails.

Can you be specific and less vague? I don't understand what the issue is.

Sorry to hear that, that's our fault I'm sure. (There's a reason many services require non-VOIP phone verification and we didn't want to go that route, this is an unintended consequence). I know you're likely not invested in the outcome of having this fixed, but if you send an email to the address listed on the contact page (https://doublespeak.chat/#/contact) I'll take a look and see how we may be able to resolve this on our end.

Thanks for the feedback, we'll review this internally either way.

Even if it reproduces (proportionally) small sections of code it's been trained on verbatim, its function is transformative and will likely be deemed fair use. This lawsuit is going nowhere other than the HN front page.

> On the whole there is a lot of good stuff, but I worry about the ability for it to stay an open standard. Today Google has dominant browser market share with Chrome, so they get to dictate new web standards just by building them into Chrome.

I think this concern is mostly obviated by the use of content schemas ("lexicons"): https://atproto.com/lexicons/atproto-com

My concern is how many of these schemas will need to be implemented for true compatibility. At this stage at least, it's still better than implementing ActivityPub.

I use zsh and have the following alias (rather, function):

``` cp () { rsync -avhW --progress --inplace ${@} } ```

If I ever need to use the `cp` binary, I execute `=cp`, which evaluates to `/bin/cp`.

I felt like prepending the domain was a reasonable request so I've added that as a checkbox. Thanks for the feedback!

Regarding the versioning, perhaps that could be manual editing of the email? or using a different "v2" salt?

Correct! This is why I explicitly said the following in the blog post I linked above:

> Once the application hits “readiness” status (as determined by health endpoints or the load balancer), the secrets volume should be unmounted and made inaccessible.

Arbitrary file read vulnerabilities are extremely common.

I agree completely. Storing secrets in environment variables is wrong: https://blog.forcesunseen.com/stop-storing-secrets-in-enviro...

Even unsetting environment variables leaves them in /proc/self/environ. There isn't a thread-safe way to unset environment variables in POSIX, so even if you `unset TOP_SECRET` from within a program the contents of /proc/self/environ will remain unchanged and available.

Sure, value for value.

I could form a business entity, open a PO box, create an <insert payment processor here> account, and accept value from those who use the service. People could pay whatever the service is worth to them. Some are in circumstances such that they're unable to pay. Those with means may be able to contribute more - it's whatever the service is worth to them. Value for value.

Agreed, running your own node gives you true ownership of your data. Those that can, should. For those that can't, community servers.

I run one of the larger Mastodon servers in the fediverse, and as far as I know the largest non-cloud hosted Mastodon instance.

Here's a ten-post thread I wrote about my experiences scaling this self-hosted instance: https://noagendasocial.com/@eriner/108115547628441425

AMA I guess