Does Social Maps use Mangrove Reviews? #12

gimse commented 2026年04月05日 08:24:52 +02:00

The question is in the header. Sorry. I don’t have time to look in the code

The question is in the header. Sorry. I don’t have time to look in the code

boramalper commented 2026年04月05日 14:16:38 +02:00

Hi again @gimse,

I replied in the CoMaps thread but copying my reply here as well for visibility:

No, Social Maps does not use Mangrove Reviews Standard nor is affiliated with its parent Open Reviews Association. It's entirely different.

Hi again @gimse, I [replied](https://codeberg.org/comaps/comaps/issues/556#issuecomment-12673743) in the CoMaps thread but copying my reply here as well for visibility: No, Social Maps does not use [Mangrove Reviews Standard](https://mangrove.reviews/standard) nor is affiliated with its parent [Open Reviews Association](https://open-reviews.net/). It's entirely different.

keorn commented 2026年04月05日 17:32:23 +02:00

Hey @boramalper I would be very keen to help with avoiding splintering of the open reviews dataset that we could build. It would be great to have a chat to see how the standard or services could be adjusted to allow your application to follow a common standard. Ping me on Matrix: https://matrix.to/#/#openreviews:matrix.org or at hello@open-reviews.net

Hey @boramalper I would be very keen to help with avoiding splintering of the open reviews dataset that we could build. It would be great to have a chat to see how the standard or services could be adjusted to allow your application to follow a common standard. Ping me on Matrix: https://matrix.to/#/#openreviews:matrix.org or at hello@open-reviews.net

boramalper commented 2026年04月05日 22:35:35 +02:00

Hey @keorn,

Replying here to have the discussion in public for better visibility and to give others a chance to contribute as well.

I love interoperability and would love to see Social Maps and Mangrove Reviews work together as well.

I think the key difference is authentication: Social Maps requires an OpenStreetMap account and uses that to authenticate and identify users whereas Mangrove Reviews is using public-key cryptography. I am not sure how to reconcile those different authentication and identity approaches (if we were to build a "bridge" to sync reviews with each other for example).

You may suggest that Social Maps too should switch to using public-key cryptography, which would eliminate the mismatch. I shared my thoughts on this in the issue tracker of Organic Maps on GitHub, copying below for posterity:

Hi @.pietervdvn,

When someone makes reviews with MapComplete.org, the private key gets stored in the user settings, using mangroveidentity, mangroveidentity-creation-date and mangrove_kid (the latter should be derivable from mangroveidentity).
This means that OM could read the preferences to reuse the same account.

Storing the user's private key in their preferences means that anyone with access to user preferences will be able to read and copy their private key. This can be catastrophic because your private key is your identity in Mangrove Reviews and thus unlike, say, access keys or bearer tokens, you cannot "revoke" nor "rotate" your private key. This gives a malicious actor full access to the Mangrove Reviews account of the user, from posting new reviews to editing and removing existing ones.

This is why cryptographers warn against "rolling your own crypto", including using low-level cryptographic primitives in place of cryptographic systems. It's just too easy to get wrong.

With modern auth systems such as OAuth, applications do not even see user passwords so there is zero risk of mishandling sensitive data. The worst that can happen is an app leaking the bearer token it got from the server, which has an expiry date and can be easily revoked by the API provider or the user, including all tokens issued to that app (for example if the app is deemed insecure).

I don't expect Mangrove Reviews to stop using public-key cryptography either so I am not sure what's the solution here. Curious to hear your thoughts.

Hey @keorn, Replying here to have the discussion in public for better visibility and to give others a chance to contribute as well. I love interoperability and would love to see Social Maps and Mangrove Reviews work together as well. I think the key difference is authentication: Social Maps requires an OpenStreetMap account and uses that to authenticate and identify users whereas Mangrove Reviews is using public-key cryptography. I am not sure how to reconcile those different authentication and identity approaches (if we were to build a "bridge" to sync reviews with each other for example). You may suggest that Social Maps too should switch to using public-key cryptography, which would eliminate the mismatch. I [shared](https://github.com/organicmaps/organicmaps/issues/2758#issuecomment-4189339556) my thoughts on this in the issue tracker of Organic Maps on GitHub, copying below for posterity: > Hi @.pietervdvn, > >> When someone makes reviews with MapComplete.org, the private key gets stored in the user settings, using `mangroveidentity`, `mangroveidentity-creation-date` and `mangrove_kid` (the latter should be derivable from `mangroveidentity`). >> This means that OM could read the preferences to reuse the same account. > > Storing the user's _private_ key in their [preferences](https://wiki.openstreetmap.org/wiki/Preferences) means that anyone with access to user preferences will be able to read and copy their private key. This can be catastrophic because your private key _is_ your identity in Mangrove Reviews and thus unlike, say, access keys or bearer tokens, you cannot "revoke" nor "rotate" your private key. This gives a malicious actor full access to the Mangrove Reviews account of the user, from posting new reviews to editing and removing existing ones. > > This is why cryptographers warn against "rolling your own crypto", including using low-level cryptographic _primitives_ in place of cryptographic _systems_. It's just too easy to get wrong. > > With modern auth systems such as OAuth, applications do not even _see_ user passwords so there is zero risk of mishandling sensitive data. The worst that can happen is an app leaking the bearer token it got from the server, which has an expiry date and can be easily revoked by the API provider or the user, including all tokens issued to that app (for example if the app is deemed insecure). I don't expect Mangrove Reviews to stop using public-key cryptography either so I am not sure what's the solution here. Curious to hear your thoughts.

keorn commented 2026年04月06日 20:43:18 +02:00

I see where you are coming from in terms of the issue with MapComplete integration, but it I think it is important to consider what is the purpose of the current standard and how integrations can be done differently.

Using OAuth would be the same as using a publicly available private key for all submitted reviews - there are no guarantees on the consistency and the reviews have credibility only because they are published by your service which claims that users have authenticated with their accounts.

Using JWTs built in crypto primitives is a fairly standard thing in web technologies and pretty far from "rolling your own crypto".

Signature in Mangrove reviews allows for two properties:

1. It ensures consistency of a review - anyone can verify that the review was not tampered with after someone has submitted it. This is not available in systems that do not utilize cryptographic signatures and especially important when building an open exchange format.
2. It allows application builders to choose an authentication setup that works best for them or delegate it to the user, rather than tying them to OSM login, while retaining stronger identity.

Putting signatures on the reviews is not a problem, question is how to do it while retaining the properties above. Reviews could be imported from Social Maps dataset periodically and signed periodically with an ephemeral key.

What might be interesting for you is the new setup that will be introduced which allows for claiming equivalence between two keys. This will allow for ephemeral keys to be used for review signing, which will remove any risks of exposure. I am actually developing a library which would make it easy to authenticate with a few OAuth 2.0 providers (including OSM) to sign reviews for the user with such ephemeral linked keys. I would be keen to collaborate on integrating such solution into Social Maps.

I see where you are coming from in terms of the issue with MapComplete integration, but it I think it is important to consider what is the purpose of the current standard and how integrations can be done differently. Using OAuth would be the same as using a publicly available private key for all submitted reviews - there are no guarantees on the consistency and the reviews have credibility only because they are published by your service which claims that users have authenticated with their accounts. Using JWTs built in crypto primitives is a fairly standard thing in web technologies and pretty far from "rolling your own crypto". Signature in Mangrove reviews allows for two properties: 1. It ensures consistency of a review - anyone can verify that the review was not tampered with after someone has submitted it. This is not available in systems that do not utilize cryptographic signatures and especially important when building an open exchange format. 2. It allows application builders to choose an authentication setup that works best for them or delegate it to the user, rather than tying them to OSM login, while retaining stronger identity. Putting signatures on the reviews is not a problem, question is how to do it while retaining the properties above. Reviews could be imported from Social Maps dataset periodically and signed periodically with an ephemeral key. What might be interesting for you is the new setup that will be introduced which allows for claiming equivalence between two keys. This will allow for ephemeral keys to be used for review signing, which will remove any risks of exposure. I am actually developing a library which would make it easy to authenticate with a few OAuth 2.0 providers (including OSM) to sign reviews for the user with such ephemeral linked keys. I would be keen to collaborate on integrating such solution into Social Maps.