Example of AvionDB with chat app? about aviondb HOT 2 CLOSED

@vasa-develop बहुत धन्यवाद!

from aviondb.

Hey @julienmalard

You can treat AvionDB as a centralized Database (living on a remote server) and follow the same practices as you would follow with databases like MongoDB.
BUT, as AvionDB is a p2p database, there is a different approach to be followed here.

This change in the approach is due to the different Access Control models. In centralized databases, you have a single entity controlling all the data and its access. But in the case of p2p databases, the users are the infrastructure; meaning the users store their own data and control access to it. (We do have an OPT-IN backup service for data resiliency so that users can recover their data when lost)

Here is how the above flow would work with AvionDB.

1. Each user maintains his own database of users (his/her contacts), messages, etc.
2. In order to register to the app, he/she can use any type of Web 2.0 or Web 3.0 auth service (email/pass, FB, Google, Web 3.0 auth projects, DIDs, basically anything). The way we integrate any auth service with AvionDB is by creating a custom Access Controller, which is basically an interface class that defines a bunch of functions.
   We have already implemented a number of widely-used Access Controller for Firebase for Web 2.0 auth and Access Controller for 16 Web 3.0 auth projects.
   These Access Controllers define who can add records to a specific database, & how to add/remove write access for a user from a database.

NOTE: The Access Controllers only control Write permissions.

3. A user only has the chat data of the chats he is a part of. Let's suppose we have a chat group where we have 5 members. Now, even if other users (other than 5 of us) don't have the address to the chat database, they could still read the chat of they get the database address. So to prevent this (meaning adding read permission) we need to encrypt the data. We are working to add out-of-the-box encryption (for data that AvionDB stores and communication between the peers), but till that is done you need to encrypt the data yourself.

4. Now, following the previous example, let's suppose we want to kick out a user from the group. There can be 2 ways to do that:

• Simply delete the keys & chat data from the app (security at the application level).
• But, application-level security is not enough. As the user can always change the application code to remove the logic to delete the keys & chat data from his app.
  To solve this issue we have been working on key re-distribution approaches. This way when you remove/block a user you can change the keys that the members of the group chat are using, hence the new chats are encrypted with the new keys, hence the kicked out user can't see the new messages (even if he hacks the app as suggested above)

5. If you want to give special privileges to a few users (admins), you can:

• Give them the special access (for editing/modifying any messages) by specifying a logic in the Access Controller's canAppend() method (which controls who can write to a database). You can add/remove the admins according to your application's needs.

To understand more deeply about the Access Controllers & how to implement encryption, see this OrbitDB field guide. AvionDB is fully compatible with OrbitDB, so this field guide applies to AvionDB too.

Summarising, the user registration/login can be done with any Auth service that you may want to use. The write access to data is controlled by Access Controllers, and the read access is controlled by keypairs. You can introduce special users such as "admins" with special privileges by adding some business logic into the Access Controllers.

This does seem a bit hard to work with as a developer, but we are working on making this easy so that you as a developer don't have to worry about all the internal technicalities of AvionDB.

If you would like to discuss more AvionDB/IPFS or Web 3.0 in general, then feel free to reach us out at our Discord Group.

from aviondb.