#  MAPTCHA Notes :tea:

Project page: https://github.com/ciupava/maptcha_dev

[TOC]

*Some description summarising aim and the general idea*

**Aim:** to protect web systems from spam while using the labour of captcha solvers to improve OpenStreetMap.

**General idea:** We have AI systems like fAIr that recognise buildings. They are not good enough to directly integrate into the map, or even give directly to mappers. On the other side, we have spammers creating bot accounts.

Some buildings are missing on OpenStreetMap completely, others were mapped wrong, and a few have been changed or demolished since they were mapped.

We would ask accounts who are suspected of being spammers to solve a challenge, asking them to click on the buildings in a selection of images. A small share of the images would be known positives and known negatives - used to validate whether the user is a bot; the rest of the images would be unknown - this is where we get free work from the user. The user would not know which are which. Ideally, the known positives/negatives would be examples that are known to be tricky for existing computer vision software.

This isn't only for buildings: we could validate the existance of other objects that are visible from aerial imagery like zebra crossings, roads, etc. or objects that are visible from street-side imagery like Panoramax or Mapillary, such as benches, access restrictions, speed restrictions, road signs...

We could also validate objects, for example the shapes of buildings if the AI prediction doesn't match what's mapped in OSM (has the building changed since it's been mapped? Was the mapping not done right?).

We would gather multiple votes on a single validation, requiring a minimum number of votes and minimum percentage of positive consensus on validation before sending the validated points to mappers. For example, if 12 users have seen an image and 80% agree that there's a building there, which OSM doesn't have, we could send it to maproulette to be mapped.

After using it on OSM we could expand... general use... sell protection on one side, data validation on the other... use the validated data to improve the training of computer vision systems.

# Minimal mockup

We can use sample data from a Mapswipe challenge, e.g. https://web.mapswipe.org/#/en/projects/-O7hFcC2pKTnTh01SGds

~~The mockup would have a dozen images. We would have labeled known positives and negatives, and a few 'fake' unknowns that we would collect votes on.~~

~~We could reuse code from open source captchas. Altcha seems popular but doesn't implement puzzle solving...~~

## Alpha version

- What questions are we asking in the interface?
- *Click all of the images where the red outline covers a building* (Stuart)
- *Click on correctly outlined buildings* (Guillaume)
- *Click on the images with correctly outlined buildings* (Anna)
- *Does the shape outline a building?* (MapSwipe)
- Would the interface have an "instructions" button? i.e. how does one behave in uncertain cases? → For the test we could just filter "easy" images (that is, where the category is obvious)
... would this would make the app less swift?
- meaning of the inputs we get from users (hypothetical question: *click all of the images where the red outline comprises a building*)

|Image <br>category |Sample image| Expected response| Meaning |
|:---:|---|---|---|
|TP |  | Yes / Agrees | Expected building (labels = prediction) |
|FP |  | No / Doesn't agree | No building in the labels, there shouldn't be any where outlined|
|FN |  | Yes / Agrees | Expected building (it's in the labels, but not predicted) |
|TN |  | No / Doesn't agree | It's an image with no outlines (not in the labels, not in the prediction)|

... shall we create fake TN with random oulines in the middle of nowhere? Or are we happy with having empty figures for this category?
Actual TN found by the algorithm (there're not many more)
 and 

## Test alpha version with volunteers

We want to send the link of the working prototype [link to GH-pages site](https://ciupava.github.io/maptcha_dev/) to a "good" amount (~~30-40?~~ hundreds!!) of volunteers.

Are we running an A/B test?
* steps to organise this:
* all ready by **Jan 13th**
* send link :mailbox: to invite people to take part ... ==*we shall write instructions for this, maybe update the README by then??*==
* give one week time to try it
* shoud we make sure that people do not see repeated images? (relevant?)
* would users see the same images?
* how many images would they see?

Number of images per "session" (9? same for the swipe type?) and among these what is the proportion of:
- known/unknowns (are we using these in the first version?) ==*we do not have "uknown" predictions yet!*==
- true/false/positives/negatives (is this actually relevant??)

**SURVEY**
We are setting up a *questionnaire* to get feedback from the users.
Type of questions (easier if it is not qualitative input, for infering some data out of it).

Questions below are of the type "strongly agree/agree/neutral/disagree/strongly disagree"

- About the user's background/knowledge of GIS stuff/origin/age?!?
:::info
I have identified features (like buildings) from satellite imagery before
:::
- pertaining the interface look
- clear
- better swipe/grid

:::info
I prefer the grid/swipe format
:::
*[@stuart make this not a agree/disagree, only 2 options here, or 3 if you add 'neither']*

- about the images
- is the zoom level OK?
- are buildings clearly outlined? (quality of prediction)
:::info
I could easily identify the detected building
*(You can add details in last question box)*
:::

::: info
I would like more/less zoomed imagery
*(You can add details in last question box)*
:::
- understandability of the task
::: info
The user would benefit from further instructions
:::
- How tedious do you find this (comparing experience with other CAPTCHAs for example)
:::info
I find this CAPTCHA tool very cool
:::

- What we missed (open question)
:::info
Is there anything we have missed and you would like to see in MapTCHA?
(For example: option for translation to other language, refresh/instructions/"skip" button, ...)
:::

- General feeback (open question)
:::info
Anything you would like to suggest, feedback or comment...
:::

## (Technical) Questions :question:

1. How do we generate the images
- from fAIr → buildings, ...more?
- detected feature points or outlines (buildings, zebra crossings) etc ... → Mapillary challenge?
2. Where is it going to be hosted? → dev.openstreetmap.org
3. Fundings?
4. How do we set the scores, weights, thresholds for validation? Start with something arbitrary and iterate?
5. Images: tiling + associate labels with the sat image...
*I have the rgb image, and I have the (polygonised) prediction... I can glue them on top of each other (screenshot is not a viable solution as we want many of them, so can create a matplotlib figure and cut with some clipping tools + grid), and can also find a way to match with the labels to check if true/false... this is a bit trickier*
6. how to choose TP/TN/FP/FN...? by visual inspection? how can we do that for 100s images, later on too?
*Temporary script that does this for fAIr imagery. It has problems with TN, which are tricky to generate automatically*
7. which zoom level to choose? 19 has plenty of footprints, 21 less, though:
8. zoom level affects n. of buildings available (obviously), but less obvious that this affects different regions in different way (depends on the "average" size of the buildings there), so might need to subsequently split the original zoom tiles in order to show only a couple of buildings
9. What makes the humans human in this task? If it's the action of clicking, then we have to deal with the situation where none of the images are clickable (i.e. either no building outlines are present, or the user doesn't see any)
*... either a SKIP or Refresh button could do the job?*
10. Rules for "goodness" of a building, is it to the user to decide or are we giving instructions? (With examples)

## Logo :tea:
- should be easy to catch
- should contain reference to: map, matcha tea, maybe safety?
- should be "iconisable", i.e. scalable to a small size - must be shown in the frontend window
-

Version used for the FOSDEM proposal (Dec 2024):

## Timeline :calendar:

~~... to present at the next State of The Map?~~
Proof of concept presented at FOSDEM 2025.
Application for SOTM EU 25 due by end of July.

# Meetings and updates :mega:

### October 15th, 2025
Attending:
- [name= Stuart, Anna]

What to present at SoTM.
1. Stuart can perform minimal tweaks on the user interface to integrate the feedback from Fosdem (i.e. accessibility + toogle on/off the polygon visibility)
2. Anna would think that the data integration (ie bring in new data from MapSwipe) has more priority, as we then build on what already exists in MapSwipe for the interface/UX UI, but we're not ready for that yet > limited time capacity and also new API not ready (see last call)
3. We explain honestly that progress has been hard because we're working on it in spare time and trying to get people on

-> Anna to start a new slide deck on Google Drive to start putting down ideas:
- building up from what presented at Fosdem, and go a bit deeper on things we did very fast
- talk more about the data
- more about the captcha
- less about the test > what we learnt from it:
- data needs to be good > Mapswipe
- interface is important > this is a feedback for fAIr

### October 6th, 2025
Attending:
- [name= Oli, Anna]
This call was mainly an update on the status of the MapSwipe API.
Togglecorp (the web development company that maintains MapSwipe, based in Nepal) is pushing the new API to production _next week_.
That means we can soon start using this for interfacing for the data.
Oli is supposed to meet with them tomorrow morning and discuss how it works (ie interact with the new system, create projects etc).
Can get additional instances up, to test fAIrSwipe and there also Maptcha works, so that there is a safe enrivornment to test.

### August 14th, 2025
Attending:
- [name= Bastian, Oli, Stuart, Anna]

- [x] Technical updates (if any)
- [x] State of the SoTM EU submission
- Anna: are we thinking of launching a test for this version too?

### July 17th, 2025
Attending:
- [name=Stuart, Anna, Clinton]

- [x] Introducing Clinton → Stuart to open a few issues for him to tackle
- [x] Notes from Oli (see below)
- [x] Application to SOTM EU [here](https://hackmd.io/@annazan/rkrQu13Hee/edit)

#### MapTcha project created on HeiGIT MapSwipe dev instance:

- [name=Oli]

* Data export of project, groups and tasks entry shared with Stuart
* How was the project created?
* Based on the aggregated results of [Validate -- Managua (2)](https://mapswipe.org/en/projects/-OSZB-J3fi_HdpigMa6B/) (quite a random choice) --> 9,548 features, each with 8 to 15 validation answers
* Filtered for features with
* an either "yes" or "no" majority result (as opposed to "not sure" or "offset"), and
* an agreement value of more than .75 (in this case, this basically means max one diverting answer per feature)
* 675 out of 9,548 features remaining after filtering
* Results unevenely distributed: 617 "no" and 58 "yes"
* Question: Can we blend in one or two uncertain results per task group?
* Open issues:
* Callback would probably need a Firebase function (definitely needs buy in from #mapswipe community, as this will generate some costs)
* Original validation results are not handed over as properties of the features in the newly created tasks --> at the current state, MapSwipe is not aware of the "ground truth" result.
* Currently, the minimum group size at project creation in MapSwipe is 10. For MapTcha, we would probably want task groups of size 9?

### July 3rd, 2025

Attending:
- [name=Oli, Stuart, Anna, Bastian]

*Agenda*
- [x] Updates from last meeting
- [x] Stuart with HCaptcha
- I dont think that HCaptcha open sources their server side components, so we would be tied to their servers
- https://github.com/altcha-org/altcha-lib seems like a good alternative that we can use with node.js for a light weight server or lambda function
- Need to see if we can provide custom frontends to it but looks like it might be interesting
- Does not necessarily do callbacks but we could set that up pretty easily I think.
- [x] Oli with MapSwipe → ...
- MapSwipe currently undergoes backend revamp, expected to be completed mid-September
- As a first step, we could manually set up a MapTcha project on the HeiGIT MapSwipe instance
- PoC to be presented to MapSwipe community
- [x] Anna with finding web developers
→ *Clinton is happy to jump on board https://clintonlunn.github.io/, he works on [OpenBeta front end](https://github.com/OpenBeta/open-tacos)*
- [x] They asked about Maptcha on Mastodon https://en.osm.town/@thibaultmol/114769302530581095
- [x] Application for SoTM EU is now open https://osmuk.org/news/sotm-europe-propose-a-session/
... Link to submission page: https://pretalx.com/sotmeu2025/cfp
→ Anna to open an [HackMD](https://hackmd.io/@annazan/rkrQu13Hee/edit) to write the application

### June 05, 2025
- [name=Anna, Bastian, Oli, Stuart]

- Introduction of the newbies :partying_face:
- **Oli** introduces the idea that from MapSwipe's perspective there's interest/overlap with the infrastructure that is already in place, for Maptcha to be used as a validation tool + _they can provide ground truth and labels_ from completed projects
- The idea is generally welcomed by the rest of the team and we try to understand/discuss the feasibility:
- **Stuart**: makes sense to build on top of what is already there;
requirements: captcha should be minimally intrusive, quick to interact with;
- **Oli** shows how MapSwipe projects creation work (the interface);
- Explains that while current Maptcha tiles are static images, MapSwipe grabs the tiles and constructs the images from a server on the fly, so technically it'd be easy to adapt for Maptcha;
- Zoom level is also customisable, as is the background imagery;
- From a technological point of view, we have all the pieces, we only started putting together a few... how do we go ahead? We need to find collaborators
- **Bastian** many projects and people under attack of scrapers would be happy to participate for public good to volunteer to have this in
- SoTM EU announced to be in November in Scotland... can this be a good deadline?
- What is our availability?
- Oli can put some effort into this, involve other people too, but needs to make it clear with the team
They can work maybe on the frontend and on the adaptation of the backend
// He is on holiday from tomorrow, back start of July;
- Bastian happy to contribute, not deep into the technology needed
- Stuart can't commit as much in the future, happy if we find someone that works on the front end → WE NEED SOMEONE WITH EXPERTISE ON WEB COMPONENTS (javascript, React, etc) TO BUILD UP ON WHAT WE'VE DONE

**Next steps:**

- [ ] write the custom standard code for adapting MapSwipe data to Maptcha use, i.e. back end → _Oli to interact with his team mates by the time of the next call_
- [ ] build front-end → _find web developers ... Anna??_
- [ ] security call back... find some people good at CV and sneaky that would want to try break the code?? → _Stuart to check the code at HCaptcha, which is open source_

### May 2025
- [name=Anna]

**7th May** → informal chat with **HeiGit** people:

- Basically MapTCHA could be a different client for MapSwipe, as it could read the same data
- Availability of validated data from past projects (some **100k images**?) that can be used as labelled/known data
- Set a call with Oli on 12th May to understand onboarding / data / how MapTCHA could be integrated within the wider HeiGit tools platform?

**13th May** → Onboarding **Bastian**!!
He says there is some literature on validating crowdsourced data - and Stuart knows from a previous job where they got to meet each other :)
Happy to join next Maptcha call.

**13th May** → Call with **Oli** about integrating MapSwipe / fAIr-Swipe / MapTCHA [* see below]

- has watched the video of the talk at FOSDEM, cloned the repo and tried to run it locally :star: (but then can't proceed as he lacks access to the backend)
- he can see a support/collaboration/integration with MapSwipe and is interested in taking part in the next Maptcha call :phone:
- many detail to be discussed, but first to understand whether we want to integrate Maptcha into MapSwipe, OR *Maptcha would just be an additional client that uses MapSwipe's backend* - as it's the case at the moment for the mobile app and web app of MapSwipe
- he showed how the interface looks like for organisations/customers that want to open a project on MasSwipe and basically there could be a specific type (of projects) for Maptcha
- data in MapSwipe we could access to, would be the ones from the validation projects (see image in Updates from October 15th, for an example): we have the known geometries (from the customer) and the aggregated classification (from the users)
... in this feedback loop we can feed in Maptcha (not necessarily OSM data... for now, until fAIr-Swipe works)
- he believes that the issues we have, namely:
- image centered to polygon
- zoom in/out the image
- toggle polygon visibility
could be solved using what already was done for MapSwipe, where the images are "interactive"...
:thought_balloon: thinking out loud: at the moment we only have static images :thought_balloon:
:question: **How do we generate images for Maptcha from MapSwipe?** There, the images/tiles are not stored, both in mobile and web app the query of *geometry of* and *zoom level for* the feature happens on the fly when the map is opened using (see :point_down:)
- the manager dashboard requires:
1. project tasks geometry
→ AoI (geojson)
→ link to geojson (we would use this one?)
→ link to HOT tasking manager ID
2. Tile server
→ Bing (sigh!), MapBox, Esri, Custom (OAM)
- :question: **To how many users you show the same image?** →On MapSwipe the users verification is 3, it makes sense that this number would be increased for Maptcha
- :question: **At the moment Maptcha is hosted on crown-shy servers, could it be hosted by HeiGit, how would this work?** → Front-end can be hosted wherever you want, back-end already exists and could connect to it - he explained something about Python workers (?) to be adapted, that Anna couldn't follow

> [*] **MapSwipe** is available as a [mobile app](https://www.missingmaps.org/mapswipe/) and [web app](https://mapswipe.org/) versions, **fAIr-Swipe** is a work in progress and once in production would do exactly what Maptcha has been trying to do until now, i.e. feedback to fAIr predictions with users' validation (and OSM labels)

### April 24, 2025
- [name= Guillaume, Stuart, Anna]

- [x] license still to be dealt with
- [x] deadlines... **SOTM EU**?? (Dundee, Scotland on 14th & 15th November 2025) → _let'start writing something!_
- [x] what we need to make it bots-proof
- [x] what we need to put it online - backend/frontend
- [x] data??
- [x] involving Bastian? → *general onboarding needed!*

During this meeting, we've created a [project board on GitHub](https://github.com/users/ciupava/projects/2) and opened/solved a few issues within it.

We reckon at the moment 2 main streams should be addressed to get MapTCHA into production state:
1. improve the data pipeline
2. assess-the-human-against-the-bot task

We want to be able to present these improvements at SoTM EU 2025.

### March 18, 2025 (Zoom)
- [name= Stuart, Guillaume, Anna]

- Feedback from FOSDEM:
- Maptcha Version 2
- the license!
- discussing the feasibility

### Jan 21, 2025 (Zoom)
- [name= Stuart, Guillaume, Anna]

- **Feedback from the test (Mastodon):**
- get rid of the Swipe version?
- TN ... outlines yes/no ... review initial question?
- zoom level
- accessibility:
- language translation
- color-blind friendly
- other format than visual
- add instructions
- **... more from the survey?**
- **Analysis of the data obtained + survey**
- **Set up slides:**
- intro: about us, idea, captchas in gen
- the data: fAIr / computer vision!? / limitations
- prototype
- test's results
- ideas for version n.2
- **Let's write a paper‽**
### Jan 7, 2025 (Zoom)
- [name= Stuart, Guillaume, Anna]
- [ ] HOT is informed and happy to hear - integration with MapSwipe might turn useful
- [ ] undiscussed points from last meeting
- [ ] general update / FOSDEM participation
- [ ] mockup test

No of images per category:
- FN 91
- FP 83
- TN 137
- TP 548

We shall need a database to store people's responses, and decide on rules about what to show to people.

Timeline: by 13th all ready, send link to potential testers with a week time to try it, get inputs and analyse them before FOSDEM

**TODO:**
Stuart → finishes off the app, updates to latest images, and addresses the points above
Anna → starts off the slides, and curates the survey questions
Guillaume → to polish off the images

### Dec 19, 2024 (Zoom)
- [name=Stuart, Guillaume, Anna]

**Agenda**
- [ ] Mockup at alpha stage :tada:
- [x] GH pages working
- [x] question in the app... also do we have one question or more? → *only ask for positives, but we can show something other than buildings, e.g. pools*
- [ ] generate the "unknown" images
- [ ] proportion of type of images per window
- [x] quality of the images
- [ ] question n.10 :arrow_up:
- [ ] else...
- [ ] organise the mockup test/demo
- [ ] number of people
- [X] where to share (personal contact, social media), type of audience/skills relevant? → *HOT people, Turing people, ...OSM community Forum???*
- [X] when → *... mid Jan?*
- [X] platform → ... *Github Pages?*
- [X] platform for the questionnaire → https://framaforms.org

### Dec 15, 2024
Proposal accepted for a talk at Fosdem 2025 [(CfP)](https://lists.fosdem.org/pipermail/fosdem/2024q4/003597.html)
See it here:
*MapTCHA, the open source CAPTCHA that improves OpenStreetMap*
https://pretalx.fosdem.org/fosdem-2025/talk/review/KMFMJ9NSWFYSW3DAGWBKK9BZFG7RBVRV

### Nov 28, 2024 (Zoom)
- [name= Guillaume, Anna]

**Agenda**
- [x] State of Fosdem application
- [x] 300 words abstract ... *almost there!*
- [x] image that goes with it
- [x] logo (see [logo section](https://hackmd.io/pZnKLf79TCGijXOUJMswBA?both#Logo))
- [ ] question 9
- [ ] publication?

### Nov ~~(19)~~ 21, 2024 (Zoom)
- [name=Stuart, Anna, Guillaume]

**Agenda**
- [x] images we have and what we could preferably have
- [x] business with HOT - fAIr
- [x] Fosdem

Update from Stuart on the status of the mockup: he started something, involving also the family :), and the Fosdem deadline is good to push things ahead*.

Discussion about Fosdem and starting the [shared document](https://docs.google.com/document/d/1QTrJVe3sx1doDVXbDbU2-JxREm-R3OQJlGpGm_QCk4o/edit?usp=sharing) for the [application](https://pretalx.fosdem.org/fosdem-2025/cfp).

> In a lot of different ways this is a design problem, not a technical problem. _Stuart_

[*] Call for participation, geospatial room: https://lists.fosdem.org/pipermail/fosdem/2024q4/003597.html

### Oct 18, 2024
- [name=Anna]

To detect buildings by category... mapping the image into categories, to assign to each building a score in terms of which category it belongs to (90% overlap threshold, or something similar)


### Oct 15, 2024 (Turing)
- [name=John, Anna]

Why it is so hard to generate (a ~huge number of) images for testing maptcha? [See questions 5-6 above]

Cases we usually see online are in general used for tasks of _image classification_, while the buildings detection is an _image segmentation_ task.


This makes it more complicated to create than, let's say, a typical captcha like this one:


POSSIBLE SOLUTION: we ask the user to draw the polygon. This would be minimal editing, i.e. to click on 4 (maybe 6, not many more) vertices that make up the polygon of the building.
We get the input from more than one user (2? 4?) and set a threshold on which they agree → this becomes our "labels" that we obtain from the user and that we can use as TP to overlay with the prediction (to assess them, as a secondary output)

**BUT**

this would imply an analysis of the inputs, which doesn't fit with the prompt detection of human/not human that we need for distinguishing from robots.

**THEN** you WOULD anyways need a (fast) yes/no type of input for the human recognition step [we could eventually use the idea right above for the data user input].

*So, where does this take us to?*
Could we maybe set up 2 steps, one initial with questions like "click on the images that contain a building" like in the second figure above (we would find "easy" cases for this‽), and a second step where people draw the buildings, to get data from the users.

**Note:**

[This](https://web.mapswipe.org/#/en/projects/-O6MPjXrwBGIbLm1pWro) MapSwipe Web project seem to do exactly it
I do see how this one can be problematic, too, and wonder how they would treat the input they get from the user.

:bulb: **IDEA !!!** :bulb: maybe we can take inspiration from the above, and use only one detection (buildings prediction outline, can be correct or not) per each image! After all, this is what fAIr currently accepts as a feedback input (on their predictions).
This should be easy to generate (estrapolate one outline at a time, zoom to it, buffer with background and export as a tile) and also to overlay with the labels mask/vector to filter them by T/F category.

---

### Oct 3, 2024 (Zoom)
- [name=Stuart, Anna]

#### Questions/initial thoughts from Stuart:

- How many people would use the the captcha every day? (How many new users does OSM have daily? Does the captcha appear also for editing the wiki? Other cases?)
- Where is it going to be used, OSM only or more widely?
- He read an [article](https://arstechnica.com/ai/2024/09/ai-defeats-traffic-image-captcha-in-another-triumph-of-machine-over-man/) recently about bots getting very good at solving the street level view ones
> AI bots now beat 100% of those traffic-image CAPTCHAs

:arrow_down:
... if you make your own captcha, you would almost hope that someone creates a bot that cracks it, then you could actually use their algorithm, as they found the solution for you (!!!)

THERE ARE 2 (almost competing) THINGS TO FIGURE OUT:
1. how secure you can make it - otherwise it's useless, as it can be used by bots
2. how to get good data out of it and gain good info from users

_**... it has to work as a security measure before it can be used for data collection**_

And this takes us to two different cases: 1. make something that works just to recognise if someone is human or not, 2. to obtain data on unknown cases (i.e. help in computer vision tasks)

The first case needs _labels_, otherwise you can't say if people are right or wrong [i.e. you need to have predictions for areas where you already know where buildings are]. In the second case we obtain data from the data.

#### What is needed
- sample data
- little interface
- test with a high number of people (volunteers)
_to differentiate human/not you see how many of the volunteers are succesful_
_... you need an answer from many people (30/40?) so that you can make sense statistically (Google has huuuge numbers)_
- test with bots??
_if it's going to be used only within OSM, then there wouldn't be many people that want to crack it, if compared to widely used captchas_
- programming language: _javascript_ (because of the frontend)
- server for storing images and results (this can be done in whatever language, python)
- a way to integrate with the existing OSM logging flow

#### Would Stuart want to take part in this :star2: project?

Acknowledging that from December to March he is in paternity leave, he can help to build a prototype interface in one or two afternoons of work.
It would temporarily sit on Github.
Anna to provide him with imagery for this [~100 images for each of the four TP, TF, TN, FN categories, with a couple of buildings per each tile].
... catch-up in person at November team-meeting in Glasgow (Stuart lives in Edi).

### Sept 27, 2024 (Zoom)
- [name=Anna, Guillaume]

Discussion of general idea and mockup concept.

**TODO list** :pencil:

- [x] get in touch with ~~Omran (~~ Benni ~~?)~~ to discuss the factibility and check interest
- [x] investigate and learn (or find someone that can learn/knows) the tech to do this - _Anna, in progress_
- [x] start github repo
- [ ] make a little plan with a graph of the idea

### Sept 16, 2024 (London)
- [name=Anna, Guillaume]

Guillaume launched ~~a name and~~ an idea for the name and logo :tea:.
First draft:


# Useful links @

https://en.wikipedia.org/wiki/CAPTCHA

https://github.com/altcha-org/altcha Open source CAPTCHA "GDPR compliant, self-hosted CAPTCHA alternative with PoW mechanism and advanced anti-spam filter." but (proudly!) doesn't implement puzzle solving.

# References, literature :book:

**Dazed & Confused: A Large-Scale Real-World User Study of reCAPTCHAv2**
*Andrew Searles, Renascence Tarafder Prapty, Gene Tsudik*
https://arxiv.org/abs/2311.10911
...
(An article covering that paper)
https://boingboing.net/2025/02/07/recaptcha-819-million-hours-of-wasted-human-time-and-billions-of-dollars-google-profit.html

**ReMAPTCHA: A Map-based Anti-Spam Method that Helps to Correct OpenStreetMap** _Stefan KELLER_
University of Applied Sciences, Rapperswil / Switzerland · [e-mail]
GI Forum 2014
https://gispoint.de/fileadmin/user_upload/paper_gis_open/GI_Forum_2014/537545020.pdf