Public Database Week #4


#1

Hi All,

Even though there is no visible progress on the website but there is something going in the background and I would like to describe it.

First of all, the activity happens in 2 public repositories today:

And there is ongoing work for UI and backend preparation.

Public Database

I would like to quick talk about Public Database and why we decide to make our life slightly more complicated for development.

As you know OpenGeoReviews is a crowdsource project and even more it is completely open. We know 2 big crowdsource projects like OpenStreetMap and Wikipedia but both of them has started before 2010, before blockchain technologies appeared. If you think of it there are big similarities between blockchain projects and crowdsource projects. Both of them need to deal with:

  • Public user registration
  • Replication between different parties and locations
  • Free form of db distribution
  • Tools & Transparency

Obviously we are not going to make a cryptocurrency and instead we are going to make something in between Blockchain & Open DB = Public Database.

Different from Blockchain

  • It is not decentralized yet. It is still controlled by 1 website & changes are validated and put through opengeoreviews.org and there is no protocol to replicate.
  • There is no tokens in the system

Common with Blockchain

  • All the changes are structured by separate Operations and grouped by Blocks.
  • The database could be recreated from log
  • Each operation needs to be signed either by user or by system

Different from OSM

  • The whole database is public including Users section (see below about that challenge)
  • There is a signature on each operation this is could be used to provide functionality like OAuth from the Day 1 and out of the box.
  • All operations are grouped by blocks and each block is a diff. There is no minute diffs and there is no hassle with missing minute diffs and other inconsistencies which breaks tools to replicate the data consistently.

Common with OSM

  • Everybody could sign up with OAuth from OSM, FB or Google
  • We request email to provide system updates about your account and provide a special ability to restore access to account in case the key is lost
  • Exports will be organized in 2 formats: block diffs and full database export

User registration challenge
Probably this is the only part which is maintained by OSMF and hidden from public. Obviously it includes some privacy data, so it is not that easy to change situation once you’ve already setup user registration.

That’s why we think to dedicate some time and do it Public from the Day 1. Here are the main challenges and solutions:

  • How is it possible to provide authorization OAuth (OSM, FB, Google) and still keep it hidden?

    • The trick that we always need to request nickname which is public by default it could be oauth id itself but user should understand that information will become public after signup
    • Obviously we can’t store *oauth id in db or hash(oauth id) cause it will be very easy to check whether person A participates in the project or not
    • On the other hand we can store hash(oauth id + nickname) which will make scanning database in case of 100 000 users very hard taking into account that hash could be a complex function like SCrypt. In this case the Authorization Server will be still able to verify OAuth and request a nickname.
  • Is it secure to have OAuth and guarantees pure login and my signature not compromised?

    • It is not. You need to trust the Authorization Server anyway cause it will provide a session login (private key) and the message of login will be signed by Authorization Server (not by you). So in that case the trust involves third party.
    • You obviously can change authorization mechanism later and provide secure public key which only you know, so the security level will be raised in case you suspect data could be manipulated on your behalf.
  • What is the most secure way to register?

    • The most secure way is to generate private / public key yourself and register pub key under your name. You can use 3rd party utility like this - https://iancoleman.io/bip39/
    • On the website we will also provide a registration with password though it should have enough entropy (at least 12 characters).
  • In case I loose my password or private key how can I restore the access?

    • This is a difficult part cause we aim not store any passwords on our site even encrypted especially in public part.
    • Though we are going to collect emails to send system updates or updates on messages, this is won’t be part of public database (the only private part)
    • There will be a functionality to suspend & reset account after X days (X will be customized by the user) i.e. user can claim that access is lost and he could restore via email which is not public and stored on Authorization Server (AS). AS will be able to reregister the user only after X days (I assume by default 3 days but probably it could be 0 days as well).

Other screenshots and progress made on design


Please let me know what do you think about the security concerns and about idea how to make new way of Public Database.

Best Regards,
Victor


#2

Sorry, but it is too comlex topic for me.
How is this account important, I mean if i loose access to account could I just create new one and continue to contribute?


#3

Awesome. Let’s make it decentralized


#4

I believe you can. It seems to be an option, but not a requirement if i understand, to use the key verification method.
Looking good Victor (you’ve probably spotted the typos in screenshots)


#5

In case it is complicated just use OAuth OSM or Google and you are fine cause you are not going too loose it.

The pros/cons: if you really want to be anonymous you should take care that some things are not recoverable. On the other hand if you think your OSM account is anonymous enough then you shouldn’t worry to use it.


#6

Does it all mean that users will have to store a lot of data on their machines just to maintain decentralization?


#7

As in all blockchain projects it will be a user choice. There will be thin client where you store only specific bit of information and full client, there will be no paradigm one size fits all