> Without committed financial skin in the game, isn't this just a dog and pony show?
Kind of: IMHO it's to 'simplify' negotiations to certain extent.
Given that Oklo is a publicly traded company, and major financial deals may have material effects on stock, there are procedures for handling those deals as if some folks know about a (potential) deal but others do not, you can get into trouble with insider information.
By public announcing the negotiations and intent then the handling of information—especially with-in Oklo—can perhaps be more flexible and less siloed, which allows more folks to talk about what's going (both internally and externally). This way the negotiating team can (e.g.) pull in any random employee into a meeting to talk about (say) technical details about connections, power factors, support, without having to worry about 'internal embargoes'.
The actual relevant question is: how many of you make a point of disallowing this? You have to go out of your way to make that not work, given that + is a valid character in email addresses.
This is why my preferred email regex is just .*@.* (I've been talked into .*@.*\..{2,} before as a slightly more restrictive pattern). And I realize there may be times/places this is not satisfactory, but it works for most general cases.
> Only a small minority of my email addresses I've ever had matches that pattern.
The example is illustrative, and not definitive, as to how the simple and innocuous decision about a regex can determine functionality, and it is not about someone going "out of your way to make that not work" to break things.
I don't know if that's what you're trying to say, but what it illustrates to me is how easy it is to quickly cook up a simple regex to filter out certain patterns in email addresses and feel like it's doing the job, while unintentionally breaking things for a large number of people you don't have on your radar.
I think I misunderstood your point before. I thought you wanted to show a regex that _intentionally_ disables it. It also happens to disable a lot more, making it a bad choice. Now I'm thinking that you might actually agree with that.
I work at a place that just recently clamped down on this. We decided to normalize the emails so that we have a column in the db like "email" and then also "normalized_email" where normalized_email has a unique key on it too. This way, people can still make their email look like whatever they want, but they also only get 1 per email inbox.
This was all because people were doing abuse more easily by churning lots of accounts while only needing 1 gmail address. Plugging this gap was a huge deal for us in reducing card testing problems.
This sounds like a very nice compromise actually. I'm surprised it helped with abuse though, since there's a lot of email providers that are easier to create an account with than gmail.
We’ve done this for a long while too. You can use subaddressing, but you’re still limited to one account per “base email”. We also normalize dots and other methods of reusing an email account.
Just changing the delimiter would probably thwart most efforts like this. I self host so am not limited to the + character. So, I currently use name-subaddress@domain. I could easily switch to using underscore as my delimiter. Or I could just use subaddress@domain. This is dead simple and I don’t even have commercial motivation. Good luck!
I mean, sure, but it does thwart the vast majority of users who don’t even know this is an option. Most people don't know you can have an email from someone other than the major providers, let alone on a custom domain or selfhosted.
At the end of the day, nothing will thwart a determined person. But that’s not the goal. If it deters the vast majority of your users from making duplicate accounts, then it’s still a success.
Yes, and another super cool thing is the prevention of accidental screwups where someone typos their email. If the typo collides with an existing account after normalization, it could be (correctly) rejected. Without this normalization index, you could have ronx@gmail pre-existing, someone trying to type "rob.x" typos "ron.x" -- and now a bunch of emails start going out to poor "ronx" (who often doesn't understand what's going on, thinks his account is 'hacked,' etc. Ideally, the system would (for Gmail addresses) reject "ron.x" knowing it's basically tied to an existing user.
> We also normalize dots and other methods of reusing an email account.
Is that limited by domain? gmail's dot handling isn't at all standard; e.g. john.doe@outlook.com and johndoe@outlook.com are different accounts, as are john.doe@icloud.com and johndoe@icloud.com.
Yes. Some of it is handled by our email verification provider while others are done in-house based on real-world experience. We handle a bunch of the major domains that our users use.
You could 'accidentally' prevent it by enforcing some incorrect regexp like [a-zA-Z0-9]@[a-z.]+
Not allowing a '+' to appear in the local part is not even that unreasonable. It's against the standard, but then "My email is this@example.com"@example.com is valid according to the standard so take the standard with a grain of salt.
It's just to illustrate that the standard is more complicated than people might realise. I think you'll have problems getting most systems to accept an email address with two @s in it, but I might be wrong. Either way it would definitely break some (not too well written) code.
Though if possible I'd err on the side of being too permissive rather than too restrictive. In the end the only true way to validate an address is to send it an email.
> Why disallow it, or use it to argue that the standard isn't good?
Because lots of folks fat finger their own e-mail addresses and then complain that a 'site sucks' because signing up doesn't work. Sanity checking to protect people against themselves may be treated as a form of UX: it's probably why some forms insist you type (not copy-paste) your e-mail twice.
I'm perpetually flabbergasted by how anyone thinks this "no pasting" thing is a pro-accuracy idea. As though people would be copying from a bad source. I see this a lot on forms for bank account numbers -- maybe one of the least amenable formats to visually copying down and retyping, since they're never written with delimiters or punctuation. I store them in my password manager, and then some idiotic form wants me to type my 18-digit bank account number, twice, on my phone, where I can't see more than one application at a time.
1password has support for a custom domain. I bought an old generic webmail provider domain that is now defunkt and use that.
I also use random name aliases on each signup. Even if you aggregate multiple breaches I doubt anybody would link it to an individual (me).
The big remaining issue is payments. I use multiple cards and rotate them regularly (I don't have access to privacy.com or similar where I am based).
I believe this is the future - feed each service you signup to a new set of information and keep track in a password managers. Most services don't care what your real name is (I've been using an alias on services like Uber for ~10+ years).
icloud is also a good option - but I don't want to signal being an iCloud user.
How else would it work? It’s incredibly convenient. The option to create a new email is presented on signup forms, or you can open Hide My Email settings and generate one. I have hundreds of emails this way
Like grandparent said: by having a catch-all email address on a domain. Then emails that are being sent to invalid email accounts on that domain end up in that mailbox.
I’m not sure that idea was thought through. An infinite number of addresses that all point to the same inbox is effectively the same as having one address
The point of having multiple addresses delivering to the same mailbox is to be able to use per service custom emails. The grand-grand parent wanted a ticketmaster specific email, so if they sell their data, or it gets leaked, they know from the email address it was from ticketmaster, or another service.
Another commenter in the thread presented how their company "normalizes" gmail addresses by removing "." character and "+..." suffixes, so users don't abuse their system by creating multiple accounts with what is basically the same email. Having a catch-all mailbox allows people to circumvent this "security" measure.
I'm imagining that you actually want to have separate emails pointing to separate mailboxes, and for that case indeed, your solution is better, but for the life of me I can't imagine why anyone would prefer having to check multiple emails, instead of a single one. :D
I've been encountering lately a surprising number of deliverability problems (as in, the emails never arrive) when I try to use "Hidden" icloud emails and Outlook.com aliases. Switching to gmail suddenly confirmations arrive. It's frustrating. Sample size of a few, but I am starting to think that companies who aren't Google are starting to lose the spam war in a way that is leading to blackholing valid messages :(
Well, you have to go out of your way to prevent it. The sub-addressing complexity is on the email provider side; ticketmaster doesn't have to do anything for it to work except not reject valid email addresses.
In my experience, most but not all sites will accept "+" email addresses.
At my current employer we do allow this. It's handy for testing and not a big deal if we have users doing this to make multiple accounts (they don't gain anything by doing that). But at a previous job it was a bigger deal and we'd strip off the sub-address part because we were trying to match up email addresses across client sites (this was due to a bit of a shady thing the company was doing and part of the reason why I left).
But a lot of popular flags are lax at employment rules—kind of why they're often picked. But you also have to have the resources for law suits, regardless of flag/registration.
> A network of clocks on the moon could work in concert to inform the new lunar time scale, just as atomic clocks do for UTC on Earth.
Presumably some clocks would have to be on the surface of Luna facing Earth/Terra, and some clocks on the side facing away, so that the gravity well of the planet could be averaged out.
And if we're going to go through the trouble/expense of sending some gear, it might be useful to pack multiple instruments: if timekeeping is a long-term need, another long-term instrument could perhaps be a seismograph to measure for possible 'moonquakes'. Multiple clocks could mean multiple seismographs for better triangulation of events.
> I'm totally fine with subscription apps, but the price has to be reasonable.
I'm fine with it if includes some monthly re-occurring service, like cloud storage/sync.
I purchased YNAB4 and I ran it just fine on my desktop. But YNAB5 went to subscription, and it included things like syncing multiple devices (which of course needs servers, which cost), but I have no need for that, and so I did not move to it. I'd much prefer I pay some one-time fee, and if I want syncing I can subscribe to just that.
I also understand that if I pay $x for Version Y, then if I want Version Z there may be an upgrade fee.
> I'm fine with it if includes some monthly re-occurring service, like cloud storage/sync.
What sucks is when the developer adds some recurring service to their software that I don't want, purely as an excuse to justify moving to subscription, and then no longer offers the software without the "service" for a one-time price.
For most of the software I use, I specifically don't want to be tethered to some kind of online service, have to have a network connection to run it, and so on. And I'll actively look for the competing software that's a one-time cost and isn't Cloud-ified.
Kind of: IMHO it's to 'simplify' negotiations to certain extent.
Given that Oklo is a publicly traded company, and major financial deals may have material effects on stock, there are procedures for handling those deals as if some folks know about a (potential) deal but others do not, you can get into trouble with insider information.
By public announcing the negotiations and intent then the handling of information—especially with-in Oklo—can perhaps be more flexible and less siloed, which allows more folks to talk about what's going (both internally and externally). This way the negotiating team can (e.g.) pull in any random employee into a meeting to talk about (say) technical details about connections, power factors, support, without having to worry about 'internal embargoes'.
reply