That's what I'm trying to test. Last time I've got 800 mostly meaningless comments.
The idea is to stop numerous zergs: you can't ban them one by one, but a little bump on their way can do the job.
To avoid annoying more serious commenters, the captcha should be as simple as it can be. So asking to add 321+625 would be too much, while a question like 2+4 doesn't need any thinking, so I chose two-digit numbers.
This is a small social experiment. I don't know how it'll go.
The captcha is basically a question to add two 2-digit numbers, e.g. 23+45. The question is returned as an SVG picture.
The hypothesis is that the need to engage brain even for 3 seconds is enough to stop 99% of the spammers, so the quality of comments should shoot through the roof.
The way it works is each comment has a sha1 hash and from that hash we can derive the 2 numbers. No state needed.
And just rendering to canvas may be very tricky if the captcha is animated with css, i.e. it moves a bit and different parts of it appear at different times.
The catch is that the text will be represented as small geometric svg shapes, so the spammer will need to first render the svg to png and then run text recognition tools. But in that svg we can easily add some css animations that make sure the entire image is never rendered, so spammers will need to run the entire browser to take screenshots and will need to assemble the image from multiple frames.
That's true when we talk about 10M monthly pageviews, but I doubt that this little extension will reach such popularity levels. If this somehow happens, by that time there will be a way to enable 3rd party captchas for any page.
Em.. "off-the-shelf OCR" sounds neat, but anyone who knows such words isn't an average spammer. The goal of basic SVG puzzles is to block 99% of the spammers who just type dumb comments on keyboards. The rest 1% can be taken care of by human mods.
TBH, I don't like the reCAPTCHA-like solutions. They are just annoying from my personal experience and if they rely on any 3rd party service, I'll give them a hard pass for this reason alone. My approach is to use trivial SVG-style captchas with adjustable complexity, e.g. instead of asking "23+34", we can ask "log(32)/log(2)" and effectively filter out everyone except people familiar with math, or "md5(2615), first 7 hex digits" and let in only people familiar with cryptography. Forcing users to detect birds and crosswalks will just make them upset, IMHO.
Or rather time-delay moderation, as it's easier to implement. Comments are added to the server as usual, but the web client shows them only after 1 hour.
I think most of the spammers can be deterred by a simple puzzle, like 23+47. If we want to raise the bar, we make the puzzle more and more complex. Obviously, the puzzle is returned as an svg picture where the letters are "rendered" with little squares. My point is that 99% of the spammers out there are lazy and won't be able to pass this little test vs someone who's written a thoughtful comment and can definitely add 23 to 47.
That's right. My first attempt was to use IPFS or DAT. Figured out it's not quite possible, but we can get very close to that, in theory. Imagine the extension or the iframe could run a ipfs.js or dat.js that would discover all the http servers with comments via DHT: servers that want to participate, publish a unique key to the DHT and the web clients discover this key and then the IP addresses of the servers. In practice, this doesn't quite work because DHTs are based on the assumption that any node can quickly ping (with a UDP packet) any other node and thus perform the DHT discovery using the Kademlia algorithm in log(N) steps. But in the web, the only way to "ping" someone is to set up a p2p connection with WebRTC: this not only needs a signaling relay, but also implies a multi step exchange with SDPs and has other costly overhead. And I haven't even approached the Symmetric NAT problem. This is why ipfs.js hogs CPU, allocates a 1 GB and keeps 4-8 sockets always open (they aren't even p2p now, but rather web sockets to some relay, for perf reasons).
Also, it's already possible to have your own comntr server: you just need to git clone the comntr/http-server repo, npm install & npm start it, and tell the iframe to use your server with ?srv=https://foobar.com:42751. This would be an "on-prem" solution.
My first post about the web extension idea got some interest (and almost 150 stars on github!), so I've made the next logical step: an <iframe> that renders the comntr.github.io page and effectively adds comments to your page. The spam problem is partially addressed by the filters: the iframe.src can have a special ?filter=[...] param that can hide some of the comments you don't like. Although it's unlikely one can bypass the security model around those filters (but you are welcome to try!), advanced spammers can still post a lot of garbage to those comments as they can easily generate new ed25519 keys.
Easily. Open source merely means that the source can be seen by anyone. It doesn't mean that readers of the source have any say in how to run the browser.
I'd expect some ML stuff, like training some models, etc. Such comments in raw form hardly have much value. What adtech usually pays for is data pinned to user ids.
Comments can be seen like this:
https://comntr.github.io#http://contoso.com/
The trick is that the #... part of the URL isn't sent to the server. This request downloads JS which computes SHA1 and gets comments by that hash from the data server.
The space of possible reasonable URLs is way too big to brute force. If your point is that someone can just grab the set of existing HN URLs and get their heashes, then I don't see what this achieves. Someone who knows the URLs can just download all the comments for them anyway. In other words, is there an example where a sophisticated state of the art hash has advantage over MD5 in our case?
Not right now. But I'm hoping to come up with an equivalent of captcha that doesn't need 3rd parties. That way any comment will need a few seconds of the commenter's time (not CPU time).
Isn't bookmarklet just a script that runs on the context of the current page when you click on that bookmark? If so, the script has all the access to your data. It can steal your auth cookie or some keys from the local storage and send them to some server.
(1) The author of this extension shouldn't have any powers to moderate comments. At the moment I can, but this will be fixed. I believe in a fragmented network with different rules about how to moderate content, or don't moderate it at all.
(2) No resilience as of today. But it should be a federated network of data servers that exchange with comments.
(3) US, if you're asking about this particular server. But it's just a demo.
(4) I own it. But again, there should be a network of such servers and it should be possible to add your own that would have access to all the comments and would be able to serve them.
(5) Commenters get assigned random ed25518 keypairs, but you can delete yours and another one will be generated. Technically, the data server knows your IP address, but you can change the data server in the config.
(6) Since comment are signed, it's possible to allow the author to edit his comments. They can't be just edited by someone else because comments are signed. At the moment signatures aren't verified, but there will be a verufy button per comment/
In fact, I seriously considered ipfs. Then I tried to patch its severe connectivity problems with webtorrent dht. I even considered dat. But internet consists of symmetric NATs, that make any such DHTs hardly possible. An extension based on js-ipfs, would need 1 GB of memory and would constantly hog CPU with some mysterious computations. It would have to keep tens of tcp connections open to maintain at least a resemblance of connectivity. Even then, if you published a comment via "ipfs add" on your laptop and tried to discover it via "ipfs get" on your phone, it would be completely unable to do so even after an hour. Yes, it is this bad. And even then, assuming ipfs add/get worked perfectly with negligible load on CPU and memory, you'd still to keep the list of comment hashes on some data server because in ipfs the key principle is immutability. No, ipns is not a solution. It does allow to change a single hash pointer, but you need to use a private key to do so. This won't scale beyond a single data server. I had big hopes on ipfs, but it really isn't there and given the fundamental problem - inability to implement fast DHT in the world of Symmetric NATs - I don't see how it can become better.