- Introduction
- Users
- How Certificate Authorities Work
- Use In Zites
- Verifying IDs
- Databases
- Dbschema File
- User Permissions
- Data File and Updates
First we will start with Users, then we will move onto Databases.
ZeroNet uses Certificate Authorities to manage and verify users. With this, there is no need to remember or manage passwords, which makes the network stronger and safer as a whole. We will discover not only the way in which ZeroNet achieves a simple yet strong system, but how it allows zites to associate a certain level of trustworthiness by the use of Certificate Authorities (known as ID Providers within the network). We will also learn about the different methods employed by these Certificate Authorities and how they are used within zites to associate data with a user ID. Finally, we will go over how ZeroNet is able to very easily verify that a user belongs to a given ID Provider, which is in turn then used to verify the data of that user. In ZeroNet, everything is signed using Bitcoin keys. A certificate authority associates memorizable ID names with Bitcoin addresses. There are currently five main ID Providers for ZeroNet:KaffieId - Names are not unique, fully decentralized
CryptoId - Names are not unique, fully decentralized
PolarId - Names are not unique, users verified by Google Account
PeakId - Names are unique, users verified by Google Account
A certificate is created for each user ID. The body of the certificate consists of a user's authentication address, portal type, and username. The user's authentication address and its private key are determined by the authentication address automatically assigned when you downloaded the ID provider's zite.
The signature is generated by the certificate authority based on the body of the certificate. This signature is generated by encrypting the certificate body with a private key. How this encryption is done varies based on the method by which the CA uses, centralized (ZeroId, PolarId, and PeakId) or decentralized (KaffieId and CryptoId).
Centralized Method
For the centralized method, the certificate authority uses a central server to generate the signature. This is so that the server can verify certain things, such as usernames meeting specific character requirements, overall length, and uniqueness. The server also generates the signature with a private key. By using a server, the private key is only known to the owner of the ID provider. ZeroId, PolarId, and PeakId all employ this method, but PolarId does not enforce unique usernames.
Decentralized Method In contrast, the decentralized method does not rely on a central server. Instead, the client generates the signature by using a publicly available private key. Because the private key is available, there is no way to ensure usernames meet specific requirements. This is why it is possible to create non-unique usernames with this method. KaffieId and CryptoId use this method, which is why they do not enforce unique usernames.
With KaffieId, a private key that is separate from the zite's private key is used to ensure people are not able to edit the zite. This also means that the public key is different from the zite's address.
Once registration is done, the certificate contents of your new ID will be stored in the zeronet_root/data/users.json file, including the signature given by the ID provider (this is done via the certAdd command).
In order to allow users to sign-in and add their own content to a zite, the zite owner must allow certain ID providers. This can be done by setting rules in a content.json file on the zite, providing it with the public key and a friendly name (usually a .bit address) of the ID provider.For ZeroId, the public key is the address of the ZeroId zite. However, since KaffieId's private key is public, the private key, and therefore public key, is not the same as the zite's address. This is to ensure nobody can edit the KaffieId website. For this reason, it is the public key associated with the private key used to create user ID signatures that should be used, not the public key of KaffieId's zite.
When a user logs in and posts content to the zite for the first time, a directory, named based on the user's public address, is created. This directory is used to store important files for the user, including any images, audio, video, etc. that the user may post to a zite. A content.json file is created within this directory, that stores the user's certificate information (username, portal type, public key, and the signature from the ID provider they signed up with).
The verification process for user IDs is very simple. ZeroNet is able to get the information of a user's certificate by reading their own content.json file in their directory. The signature is decrypted based on the public key given in the zite's content.json file. If the signature matches the certificate information stored in the user's content.json file, then the user is valid and ZeroNet continues to download and check the rest of the files in the user's directory. ## Databases Now that we have gone over Users, it is time to detail Databases, which have a direct link to Users.ZeroNet makes use of SQLite3 databases. The usage of databases in ZeroNet are very different from databases used on the clearnet. The main reason being ZeroNet is decentralized. This decentralization also requires that receiving updates from users should not be instant. Not only is there a waiting period of 30 seconds between content publishes, but there is also a waiting period for all of the changes to be spread across all peers of the network. Keeping this in mind, ZeroNet needs a way to ensure that databases are not overwritten when two people publish changes at the same time. In order to do this, ZeroNet creates separate json files for each user that will store all the information that should aggregate into the database. With this, a user only affects his own json file, meaning that these files should never be overwritten by someone else.
All zites that use a database must have a dbschema.json file. This is a json file that simply details all the tables and columns of the database. It will also tell ZeroNet which json files should be aggregated into which tables inside the database. ## User Permissions Typically a user's files, including their json file used for the database, are stored within the data/users/[auth_address]/ directory of the zite's root directory. In order for the zite's owner to be able to control what the user can put inside this directory, they use a content.json file located in the data/users/ directory. This file controls which ID Provider users can use to add to the zite, as well as which files are allowed within their user directory and the file size limit. Users also get their own content.json file located within their user directory that will tell ZeroNet what files they've uploaded and their respective size and hashes. This is used to verify that the correct user files are being downloaded. ## Data File and Updates Usually, zite's use the data.json filename for the file that will store all of the user information that should be aggregated into the zite's database. Whenever the zite updates user content (which can only be done by the user using the zite on their own computer), the updated information is added to this file.Once this file updates, zites will usually instruct ZeroNet to sign the user directory's contents, which will add the hashes of all the files, including data.json, to the user's content.json file. Then, it will add a signature to the file. This signature is generated by creating a hash of the content.json file and encrypting that with the user's private key (which is located in the zeronet_root/data/users.json file). This is very similar to how a zite owner signs his own zite.
Finally, the zite will publish the changes, which will give to at most 6 peers, the new content.json file. These peers will verify the user using the methods described in the first half of this tutorial. Then, they will ask for the other files. Once they have been downloaded, they will verify these files using the hashes provided in the content.json file and publish the content.json file to more peers until there are no peers left that need the file.
Once a client receives a new data.json file, it will add the new information into the database and send a request to the zite. A zite could then respond to this request and reload the contents on the screen with the updated information by requerying the database.
krixano - Zero Net Dev Center