protoduction

Friendly Captcha (https://friendlycaptcha.com) | Remote, EU timezone | Part-time or hourly basis | Full-stack developer

We are a small, profitable company providing a privacy-friendly and accessible alternative to Google ReCAPTCHA based on proof of work. We are looking for a fullstack developer to help us further improve our anti-spam tools that don't carry an accessibility and privacy cost to end-users. The ideal candidate is a generalist, has strong knowledge of web APIs, has experience with open source, and has built a SaaS product before.

Technologies:

* Typescript, Go, HTML, CSS (and likely React in the future for a revamped customer/admin dashboard)

* Serverless (Cloudflare Workers) as well as good-old load balanced services (in Go)

* Redis, FaunaDB, Postgres, Clickhouse

* Git, Github Actions, Sentry, Stripe

* Plugins for Wordpress in PHP, and Flutter (Dart)

Reach out to me at guido@<our domain name>.

I think the main usecase for Python in the browser using Pyodide is to enable scientific computing and visualization in the browser, and also as a way to ship small Python applications to those that don't have Python installed (e.g. drag and drop a CSV file which gets processed with pandas). Lastly it's useful to power interactive coding environments without needing to spawn a pod per user (and fighting off people using them to mine bitcoin).

Building a website or SPA entirely backed by Python seems like the wrong use of this technology. The same goes for crunching large amounts of data.

If you want to play with Pyodide in a web notebook you can try Starboard [1][2].

A sibling comment introduces JupyterLite and Brython, which are Jupyter-but-in-the-browser, whereas with Starboard I'm trying to create what Jupyter would have been if it were designed for the browser first.

As it's all static and in-browser, you can embed a notebook (or multiple) in a blog post, for instance to power interactive examples. The bundle size is a lot smaller than JupyerLite for the initial load - it's more geared towards fitting into existing websites than being a complete IDE like JupyterLab.

[1] https://github.com/gzuidhof/starboard-notebook

[2] https://starboard.gg

The host-it-yourself easiest method is to use starboard-wrap [0], it provides a custom HTML element that wraps the sandboxed iframe. Documentation is a bit lacking, but I'm happy to help out. It should work in any framework.

Alternatively you can create your notebook in starboard.gg and embed it using a standard iframe. It depends a bit on what you want your app to do, if you want to integrate "tightly" with the notebook the first will be the better choice.

[0]: https://github.com/gzuidhof/starboard-wrap

Yes, this is Javascript. Or well, at least it's web (JS+HTML+CSS).

The difference between this and Jupyter (which I assume you may be familiar with) is that this doesn't talk to a backend server. Most other notebooks do (Jupyter, Livebook, rmarkdown, Spyder, VSCode+Jupyter), which has benefits and disadvantages.

Everything here is in-browser and within a sandboxed iframe, which has the benefit that I can post a notebook where you can actually make changes/interact to an audience of millions without having to spawn a container per user. But also you can embed a notebook on your blog, it's just a webpage.

With WebAssembly being a thing now you can even have Python cells through Pyodide (which includes common scientific packages such as numpy, pandas, matplotlib), and from Python you can interact with Javascript code in the dom. So you could make a notebook that is something like: "Drop your CSV file, parse it using Pandas, visualize it using matplotlib". That's actually really powerful for distributing small programs (<1k LoC) to people who don't have Python installed on their PC.

The about page has some more thoughts on all of this.

[0]: https://starboard.gg/about

I am building something similar [0] (think Jupyter for the web, without the Observable black box, supporting clientside Python), also to scratch my own itch. I think you need to solve a problem directly, instead of being "a new tool that I now have to learn".

In my case I am trying to get Javascript/visualization/web developers to embrace the literate programming paradigm. The tough part here is that those familiar with something like Jupyter don't often know web APIs very well to really build a simple "app" in 100 lines, and those who do have probably never used a "notebook" at all and wouldn't even consider it.

How I am currently adressing this issue is by embracing content authoring first. The base of my tool are now WYSIWYG blocks, with the "super powers" being use-as-you-learn. Think gitbook but it's actually notebooks: that's not too scary. In your case it may mean some pre-built drag and drop no-code visualizations.

Importantly: don't give up now. My project has gotten some attention, but not nearly as much as I think it deserves. Follow the advice of others: see who really has a need for your product and let them help guide your next steps.

Finally, check out ellx [1] too as it's quite similar in its target audience.

[0]: https://starboard.gg [1]: https://ellx.io/

I'm building Starboard [0][1] which I believe will popularize literate programming on the web. It makes making interactive educational content, simple web apps, and documentation 10 times easier.

Think Jupyter Notebook but built for the web.

[0]: https://starboard.gg [1]: https://github.com/gzuidhof/starboard-notebook

If anybody is looking for a free alternative that just works, I'm using [1] for a demo on my product's homepage [2]. I suppose it is a bit different in scope though (updated daily instead of near realtime).

[1]: https://exchangerate.host/ [2]: https://starboard.gg/#visualization

You could run them in the browser using something like Pyodide [0]!

[0]: https://github.com/iodide-project/pyodide

I'm really biased as I am building it myself: Starboard Notebook puts literate programming into the browser without a lot of magic.

It's amazing what browsers can do these days without any build step!

[0]: https://starboard.gg

I agree that Nano has potential to actually be a currency, but does it actually matter? Those that buy a cryptocurrency hoping that it will increase in value 100-fold are not likely to actually use it to buy pizza.

What it needs is actual adoption in the real world. I want to be able to buy a pizza with it, but nobody seems to offer it as a payment option yet.

Perhaps what will make it take off is some video game or other digital economy adopting it as their in-game currency. It seems perfect for that.

It's just a landing page you are looking at for which I wanted to put down some numbers. The product [1] is very much pay-per-use (per e-mail sent), so the number shown here is more of a minimum monthly charge.

That said, I will probably double that number (and the included usage) prior to launching.

I expect there is a large difference in the quality of your users whether it's actually free or it's $4 per month.

[1]: https://magiclogin.net

Interesting article, and I think we (I'm the author of the submission) may both be right to some degree. I wrote the article with an small/indie SaaS business in mind, which often targeting other small-medium businesses and developers where the goal is not necessarily to become market leader.

The intent was to say in a convoluted way: focus on those that value your business, and in particular focus on paying customers (the higher the better). In general it's better to have fewer customers that pay more and pamper them.

If you have millions of users the story is very different of course.

Hi, author of the page here. I didn't expect this to end up so high on HN.

You're right that there is a place for free plans, the article I wrote is probably too one-sided. I planned on adding an extra section near the end for some cases when a free plan does make sense (I will wait until it is no longer discussed here).

Other than the "influencer" angle you mentioned, it also makes sense for products where you can offer the first X units for free, and many will have the desire for more (2 free designs for a website builder, or the first 10 levels free in a video game).

So it depends a bit on what you are hosting, but a real concern for myself at least is the value that free users bring to your service.

I'm not talking about the costs of running your service to support them, but everything else. A part of your free userbase will expect the world for free and start demanding more, and as they outnumber your paid users by so much it can just be a huge distraction. The question is how many of these free users will convert to paying users?

I personally add a free tier to my products because I want to make the tool accessible to hobby and other small projects without a budget, but it's probably not a good business decision.

Something I've been considering: charge some small one-time payment, say $10, for a lifetime 'try-out' plan. Then when they want to upgrade to a subscription you give them that $10 as a discount for their subscription. It may filter those users that will never upgrade anyway.

I don't think that's fair, the author is not selling anything - they took the effort to put together a good resource for others to use and are sharing it for free.

Merry Christmas, and to those who don't celebrate Christmas I hope you also have a wonderful time and are able to take a break from work.

The pricing is listed on the website, but it's about 10-20% of that. You would pay around 0.50 per 1000 emails. Depending on how often your users sign in and how long you keep them logged in for the the percentage may be lower or higher.

Not offering SAML/SSO/OIDC etc simplifies the problem a lot allowing me to offer it cheaply. The largest cost is sending the e-mails reliably, for which I am wrapping Amazon SES.

You can extend this idea to include a one time code in the email that can be manually typed on another device.

Including a QR code of the link also helps.

The base idea is the same yes, but the pricing and featureset are different.

Magic.link is venture funded with steep pricing per user. This makes sense for their enterprise target market, but for a hobby project I can't remotely afford it. They keep a record for you of your users, in my product that's your own responsibility (which imo is a good thing).

tldr: What I'm building is simpler, and much more affordable, but not enterprise-feature complete.

I'm toying with the idea of building this as a service (I made a landing page last week [0]), but I'm not sure enough would pay for the convenience of having this as a service. The service would handle token generation, verification, and e-mail sending through an API.

[0]: https://magiclogin.net

I realize this may bring in a few dollars per month for the domain owners, but do these websites provide any real value?

If you are scraping the content from the web anyhow the user would be better off going to the original source, or a moderated environment like Reddit I would say?

I've been embracing Cloudflare workers for more and more small websites and APIs, so much so that I ended up writing a small Koa/Express-like framework for it to make it more similar to 'normal' Node/Deno development [0]. Currently working on a starter template [1].

Cloudflare Pages sounds like a competitor to Netlify/Vercel mostly - paired with Workers it makes it very compelling. Slowly it's becoming a one-stop shop for me for small-medium projects that don't require any real compute.

[0]: https://github.com/gzuidhof/sunder [1]: https://github.com/gzuidhof/sunder-worker-template

You can give Starboard Notebook [0] a shot (a tool I'm building). It doesn't have reactivity which is as powerful as Observable - it's closer to normal web programming.

Here's an example notebook that shows p5.js use (with Python interop as a bonus): https://starboard.gg/nb/n3DYopT

It supports local or self-hosted editing and viewing [1] and is all open source.

[0]: https://starboard.gg [1]: https://github.com/gzuidhof/starboard-notebook and https://github.com/gzuidhof/starboard-cli

Have you considered something like Discourse[0] for this usecase, or are you looking for something more minimal? I'm trying to understand the usecase better.

[0]: https://www.discourse.org/

It's not perfect, and you are right about the downsides. These resources that spammers have can be applied as easily to re/hcaptcha (either through ML or clickfarms). No CAPTCHA will actually lock out targeted attacks.

The difficulty increase per IP can be seen as a form of soft rate limiting, it's shared between all websites (which is where it's different from ordinary rate limiting). In the future we may use IP reputation lists to guide the initial difficulty too - but we haven't implemented that yet.

I think that no perfect captcha can exist, which is inherent to the problem. Proof of work makes different fradeoffs, and perhaps it is cheaper to attack still - I think it's a much more friendly solution for users though (accessibility, privacy, simplicity, fairness, UX).

Maybe in the future the solution would be something like this: a long PoW-based captcha that runs in the background as well as a vision task for the user, whichever gets solved first.

You're right that there is an electricity cost to solving this type of captcha - the same as there is an electricity cost to loading 2MB of JS+images and clicking the pictures with the fire hydrants (and the infrastructure behind that). It's hard to estimate how they compare (and what value you assign to the human labor performed and privacy loss).

20 seconds would be a fairly high difficulty. It's up to the site owner to decide what makes sense for them.

If anybody comes up with a useful computational task with a small bundle size that can be verified cheaply that would be the holy grail - until then the computation is only there as a form of hashcash.

We don't disable the service if a protected site goes over their limit.

Right now we manually look at the limits and are reasonable with overages - also we can see how many captchas were unsolved.

You can change this behavior of the widget (data-start="auto" instead of default data-start="focus"), or you can start it programmatically.

The reason you wouldn't always want to start it in the background is if the user may not intend to submit the form (perhaps it's a form that is in your footer of every page and only a small percentage of users intend on sending it). Starting it on focus of the form is a good default.

That's not good, could you maybe provide more details in the Github repo [0]? The widget is open source, hopefully we can figure out what is blocking it here.

We test the captcha in browsers up to 8 years old and on many devices, do you perhaps have background workers disabled entirely? Here is a link to the widget on its own [1], does that have the same behavior? How about a minimal worker example [2]?

[0]: https://github.com/FriendlyCaptcha/friendly-challenge [1]: https://unpkg.com/friendly-challenge@0.6.1/index.html [2]: https://jsfiddle.net/christopheviau/90syrp0q/