[OSM-dev] Client trustworthyness

[Matt Amos]

2009/6/17 Iván Sánchez Ortega <ivan at sanchezortega.es>:
> El Miércoles, 17 de Junio de 2009, SteveC escribió:
>> So it looks like you grab a node and it has id^H^Hversion n and you upload
>> after changing it n+1. Or something.
>
> AFAIK, the API doesn't work like that. When uploading data, you have to
> provide the version number you downloaded, *not* the expected version.

"or something" :-)

>> Curious, did anyone look at throwing tokens around instead of versions
>> or some other way where you don't have to trust the client? I assume
>> this would be computationally expensive.
>
> So what? I could always download the latest version number of every element
> just prior to uploading it. Even if you want to use the weirdest crypto hash
> scheme ever invented, I see no way you could prevent malicious clients from
> re-downloading versions/hashes/tokens or whatever.

we looked at doing this during the last API 0.6 hack weekend. as ivan
says, its not a solution to the problem - its only value is that it
might make people think twice about avoiding proper merging.

short of some idiotic exclusive locking scheme, we just have to trust
mappers and their clients. there's always the element history in case
that trust is misplaced ;-)

cheers,

matt