tusharsoni

mCaptcha is basically a rate-limiter

This is a much better explanation of what it does than captcha where I expect "proof-of-human". A PoW based rate-limiter is a really interesting idea! Usually, the challenge with unauthenticated endpoints (ex. signups) is that the server has to do more work (db queries) than the client (make an http request) so it is really easy for the client to bring the server down. With PoW, we're essentially flipping that model where the client has to do more work than the server. Good work!

haha yeah, gotta keep the tradition going

Thank you! Go supports embedding static files natively [1]. Copper builds on top of it and provides the tooling to do it seamlessly for web projects.

[1] https://pkg.go.dev/embed

Thank you, so much to do in this space! Bud looks great and I see we share many common goals. The dependency injection piece looks interesting. Did you build it custom or integrated an existing solution?

They're on top of my list to add to Copper. As soon as we get sqlite support!

I think that remains a very valid use case. In Copper, you can create one of those with the CLI. For example `copper create -frontend=vite:react github.com/nasa/starship` will create a react app with a JSON backed API ready to go

This is a good observation. One trend I'm noticing is that the "old way" (PHP, Rails, etc.) of doing things is making a comeback. Go is very well positioned for this but lacks the frameworks.

I'm hoping to add something like Phoenix to Copper. It should help with the "heavily API only side" problem. I've already added integrations for Tailwind and added some utilities on top of the templating (going to add more) to fix the lack of good templating.

ha, add me to that list :) I think it's fine if CLIs are optional and I've tried to do that with Copper. Of course, your initial setup will be longer without scaffolding so it's not a great first time developer experience

Code generation is an awesome alternate, I'm more familiar with sqlc.dev. They're doing some really interesting work.

My goal with Copper is to provide out-of-the-box integrations with popular solutions to various problems. For now, I picked GORM but I definitely see adding support for other tools.

Oh that's fun! In my demo video [1], I build a (minimal) HN clone so hopefully that answers your question in detail.

But the tldr is - you'll need a lot more than just templating for a production ready app. To name a few things - server, storage, migrations, logging, configs. IMO there's a huge benefit in having a batteries included toolkit that stays close to the stdlib - so you can totally keep your templates as is!

[1] https://vimeo.com/723537998

Please do! If nothing else, it's definitely a fun language to learn. We're also setting up a community of folks who are learning Go/Copper. Check the project readme link for the link.

It kinda does but there's a lot of boilerplate that goes in before we actually get to the app logic. And, understandably, there's no structure provided by the Go stdlib. Once I made many projects with just using stdlib, I started taking common packages out. And Copper is essentially that. I can start writing my app code with minimal setup / boilerplate.

Because not all cookies are regulated (such as session cookies). It would be hard for browser to tell what the cookie is for.

Can't load the page, getting too many redirects: ERR_TOO_MANY_REDIRECTS

Thank you! ListMonk looks great but I'm not sure what their future plans are so it would be hard to do a fair comparison. For DropList, the plan is to move towards email automation using drip campaigns.

Hi HN!

Author here. I work on several projects that require me to stay in touch with the customers and keep them up-to-date on new initiatives that we are taking. I have tried several marketing platforms such as Mailchimp and Sendy. However, they can be really expensive or hard to maintain/set-up.

The goal with DropList is to have an open-source [1] marketing platform that can be easily self-hosted. But, we do provide a hosted version [2] for convenience at a very low cost. Over time, I want to add features for email automation, complex segmentation, and more.

If you have suggestions or any other feedback, please leave comments here.

[1] https://github.com/tusharsoni/droplist

[2] https://droplist.email

- No good reason really. I prefer having "app" in the URL and I was already using app.autogradr.com subdomain for an older version. During the migration, I had to keep both of them running so I opted to get the new domain.

- That's a good point about the role. Surprisingly, it is not common for users to switch roles. I had punted this functionality until I would need it but even after a lot of usage, no one has requested for this feature. However, as an instructor you can get the "student" view.

Yup! Keep an eye out for it in the next week or so.

This is a Go service so it should be a lot simpler to get it running.

These are so well thought out!

It's funny you mention dropping some letters because my other project is AutoGradr :D

This is awesome! Definitely shortlisting senditall.email and droplist.

I saw Sendy and the product seems solid, although a little dated. I wonder if a more modern, hosted competitor to Sendy would be appealing to enough users.

I especially like their non-subscription based pricing model. I would opt for something on the lines of per-campaign pricing.

The apps are native but still seem to be using HTML views [1]

[1] https://twitter.com/dhh/status/1275906524569731072?s=20

You make a good point to not use automated testing fully. I would highly recommend using some level of automated testing in every classroom.

Without automated testing, a lot of energy is spent on making sure the program runs and does what it's supposed to. Since students use all different kinds of environments (especially in beginner courses), just getting the program to run is a big challenge. Lint reports are great and I recommend adding them as part of the automated testing stack.

One huge advantage of automated testing is that students know before submitting that they understood the problem correctly, their program does what it's supposed to, and they are submitting it in the format that the instructor is expecting it in. A realtime feedback loop will always result in better submissions and grades.

Of course, once the basics are out of the way, instructors must look into the code to make an evaluation of whether the problem was solved the "right way" - whatever that means in the context of the course.

Source - I maintain a tool that automatically grades CS assignments and have collected a lot of data points over the last few years.

Excellent writeup! About 4 months ago, I wrote a comment[0] on HN telling folks how Apple simply omitted the server-side validations from their WWDC videos. And given the lack of good documentation at the time, WWDC videos were what most developers were following.

Even then, the only "security" that developers had was that the attacker wouldn't know the victim's Apple userId easily. With this zero-day attack, it would have been trivial for many apps to get taken over.

[0] https://news.ycombinator.com/item?id=22172952

Thanks for the helpful advice!

Totally agreed about learning from existing models especially the ones used in China. I don't think a model that works in the US or Europe will necessarily work in India.

Indian markets offer "mutual funds" which are very diversified and some of them carry low fees. The plan is to make sure new investors know of this option.

1. Agreed, I'll add that asap. 2. I should make it clear that the company does exist and is registered. 3. India's financial system is tricky but I'm well positioned to start a new brokerage. The problem that I'm dealing with is building a product around it that users actually want.

I don't think you should equate giving you an email address with the willingness to become a user of your product, once it exists. If you end up building this product, it would be interesting to hear about your "conversion rate" for these early emails.

Of course, the conversion rate won't be high especially if the time between the user signing up and the launch date is very long. But it is still possible to keep the interested users engaged and some of them (not sure how many) will be the seed for the first set of actual users.

And on the flip side, I personally am very reluctant to give out my email address to an entity that is essentially a company that doesn't exist yet, with a product that doesn't exist yet. Even if I'm very interested in the product in theory. (In this particular case I'm not in your target group.)

I think that's fine. Your email, your choice. But the company does exist and the product is in the design phase.

Finally, here you write that you are essentially only collecting emails at the moment, while the submission button on the website says "Get Early Access". That is very vague, but to me it suggests that you are at least actively working on development and will have a beta or at least an alpha sometime soon. So I find this very dishonest. Dishonesty is not a great look for an entity that harvests emails, or one that hopes to provide financial services.

This is totally valid criticism. I hope to convey that by signing up, you will be the first set of users to get access to the product when it launches. And while we haven't started development, we are in the design and user testing phase. The whole idea is to test ideas before developing.

All in all, I don't think this is the "right" way to launch this product at all.

I don't think there's one right way to launch. The only theory being tested here is to test each and every single idea before going into development. Since this product will be more expensive to build, it is even more important now.

Misleading title - Facebook doesn't have to pay anyone. It's a study that asks people how much they value their data.

As a developer, it's our responsibility to provide users with at least 2 options. While Sign in with Apple is convenient and seems to be fairly popular, users should be in control of their data.

Some stats from my app where users have the option to either Sign in with Apple or use their phone number:

73% use Sign in with Apple and the rest using their phone number.

If it was a privacy issue, wouldn't people rather trust Apple than an indie developer?

The biggest one is that you're essentially trusting data that the client is providing (Apple gives user id to the client and the client sends it to the server). Unless you can verify the token and exchange it for your own session id, you're opening up your users to be easily impersonated (if they get a hold of the user id).

Other than that, Apple also provides server-side verification for the validity of the token. Without that, the client could send a random string and the server wouldn't know the difference.