(Author here) that's more or less what I have right now – one machine with a file system and an SSD. S3 API on top is there to give multiple web servers shared access to the same storage. I could have used something else instead of S3 – say, NFS – but there was a feature request for S3 [1] and S3 has a big ecosystem around it already.
Yes, I "fixed" it by disabling pull requests on the repository. I'm still happy to pull from other people's branches (and do say so in CONTRIBUTING.md)
that's just a funny claim from multiple angles. a professional editor working with professional shot footage is an entirely different creature than someone that can work with a pile of footage with no guidance to create something. feature film editors are different from documentary film editors which would be closer to content creators.
a professional editor will take longer as they are laughing/crying about the dumpster fire of footage dumped into their bay. a content creator is just going to yolo jump cut their way through it with absolutely no regards for the same criteria a professional editor would be looking for. you know, things like continuity, different angles, cut away shots and other things to make a clean edit. so yeah, something you just taped on your system with no regards to normal production quality will take a professional editor longer just to get their head wrapped around it.
> If you have used Stripe before, Mollie is the closest thing to that experience in the EU.
But Mollie does not even properly support recurring payments, a pretty important feature for SaaS. It does not track subscription state and does not retry failed payments.
How about a signup flow where the user sends the first email? They send an email to signups@example.com (or to a generated unique address), and receive a one-time sign-in link in the reply. The service would have to be careful not to process spoofed emails though.
Another approach is to not ask for an email address at all, like here on HN.
Oh god. Tell me you've never dealt with those in real life without telling me lol
Usually the very best you can do IRL is "probably fine" or "maybe not fine" and that's just not good enough to justify blocking customers. Email is an old tech and there's a lot of variation in the wild.
It sounds appealing at first because it flips the trust model... instead of the service initiating contact the user proves control of their email up front That feels cleaner and arguably more robust against certain classes of abuse
But from a UX standpoint its a nonstarter
Youre asking users to
- leave the site/app
- open their email client
- compose a message or at least hit send
- wait for a reply
- then come back and continue
Thats a lot of steps compared to enter email -> click link. Each additional step is a dropoff point especially on mobile or for less technical users. Many people dont even have a traditional mail client set up anymore, they rely on webmail or app switching which adds even more friction
It also introduces ambiguity
- What exactly am I supposed to send
- did it work
- What if I dont get a reply
From the service side youre trading a simple well understood flow for a much more complex inbound email processing system with all the usual headaches (spoofing parsing delivery delays spam filtering)
In practice most systems optimize for minimizing user effort even if that means accepting some level of abuse and mitigating it elsewhere. A solution that significantly increases friction... no matter how principled...just wont get adopted widely
So while the idea is interesting from a protocol design perspective its hard to see it surviving contact with real users
I think the main UX obstacle is that it is unfamiliar – no-one does signups like that currently. But the flow does not need to be quite as bad, if you use "mailto:" links. In the happy case:
- user click on the link
- their email client opens, with the To:, Subject:, Body: fields pre-filled
- user clicks "Send"
- a few seconds later a sign-in link arrives in their inbox
Disagree. The UX would be pretty similar. Click a mailto link which opens the email client with to, subject and body precomposed. Click send. Server receives mail and the web page continues/finishes the sign up process. No need for an email reply.
It’s different, but it’s not crazy.
Ok, and a lot of -- maybe most -- people won't have their mailto handler set up correctly. I don't even know if I do on my current laptop and I have email old enough to vote
Ignoring the fact that mailto won't work for most people (it opens my Mail app which i never used), "different" is enough to make your conversion rate tank. It'd be unreasonable for anyone in charge of making product decision to go with that
Amidst all the age verification and bot spam going on, anonymous private/public key proof of identity could work: the newly signed up service must pass a challenge from the mail server to prove the user actually intended to sign up. Though I guess that would be basically the same thing as the users server initiating the communication. Really, just an aggressive whitelist/spam filter that only shows known senders solves it too, but as I understand part of the attack is having already compromised the mail service of the target. Having a third decoupled identity provider would resolve that, but then that becomes a single point of failure…
> If a bot creates an account with someone else’s email, the victim gets one email, if they ignore it that’s the end of it. The welcome email and everything after it only fires once the user verifies.
As a user, I would prefer no welcome email at all.
Yeah, thats part of why I hate "login with SERVICE". The big benefit would be not spamming me, but they always insist on getting my email.
There was a time were you would have to select "sign me up for your newsletter" then you had to uncheck it. Then you had to check to not get an email and now you don't even get that choice.
And lately? You have to go dig through your email because you can't set a password (looking at you Claude), so you can't filter email.
Yes, correct. When I clicked the link I was already welcomed by the welcome page (which is, for the most part, welcomed). But then why send me another email further welcoming me? I already feel welcomed! And don't give me any of that "because it works" BS (even though that is what you are going to say).
(cuu508, "you" in this instance does not mean you)
reply