Oasis Parcel integration

[HarleyAppleChoi]

Integration with Oasis Parcel and Desmos

Oasis Parcel is used to collect users' sensitive data (eg. location of the post, metadata of user's interest, etc).

The data should be accessed using the user identity present inside the Oasis account, which cannot be associated with Desmos. Oasis identity should only exist on the user end when the user logs into the Oasis account.

In order to get a production standard, we should consider scalability, capacity, and elasticity of the project. Clearly the approach of the prototype, which saves the whole post into the Parcel database, is a heuristic approach and not smart enough for production. The best approach is using the value of PostID as a key and store different parameter as a value for each user.
The user interest file should allow to save different interests individually per each user. When a recommendation is required, Parcel Computing will take all the files that are authorized by the Tank server and do collaborative filtering and other content based filtering. Then, Parcel Computing can act as a recommender to get the recommended post ids, and return them to the Tank server. Then Tank can get the post from DJuno and return them to the end user.

In conclusion, PostID and User Identity pairs are essential for the system to store the information successfully. However, the Desmos chain implementation is not optimized for the workflow:

• when the user sends a post message to Desmos, PostID is not returned, and there is no way for the user to know such id immediately;
• if we crawl the posts from DJuno, there is no way to connect the user's Oasis account associating it to the post.

Here is the proposed workflow using the location service as example. The red part highlights the feature that can be improved on Desmos:

The quick solution is to implement the ability for MsgCreatePostResponse to return the generated PostID value.

[RiccardoM]

Before proposing anything, I need to get this right. Please @HarleyAppleChoi correct the following reasoning if it's wrong in any part.

What
We want users to be able to get recommended posts without having to give up their personal data.

How

1. Users grant permissions to applications like Google to track their interests.
2. Applications like Google track the user interests.
3. The users interests are uploaded inside Oasis.
4. The users grant permissions to Desmos "Tank server" to access their interests.
5. Desmos "Tank server" requests to Oasis the posts that are interesting for the user.
6. Oasis returns the interesting posts to the Desmos "Tank server".
7. Desmos "Tank server" returns the posts to the user.

Existing problem
In order for point (5) to work properly, we also need to upload the different posts inside Oracle itself.

What I don't get is the following: should posts be associated with a user profile? Can't these be put inside Oracle from DJuno itself? Why do we need to associated them with a user on Oracle?

[HarleyAppleChoi]

1. We assume Google and other service do not have the ability to upload user interest to Oasis by itself. Just like Mooncake, which do not collect user interest by itself. And how the Google come from? Do we have any integration with it?
2. All user interest data should parse along Tank, as I show in the diagram.
3. Posts (which is candidate of posts that user may interest) are related to user profile. User interest is related to oasis account. To recommendation, posts has to relate to user interest. Therefore, that is easier to say oasis account is in sort of related to users posts.
   @RiccardoM

[leobragaz]

@RiccardoM I've studied a little bit the Parcels' docs and this is what I've understood, briefly summarised here:

1. User's interests need to be uploaded inside parcel by the user itself or from a DApp on his/her behalf;
2. Once uploaded, the user ONLY has access to these data;
3. DApp ask permissions to use these data;
4. User grant/refuse to give them;

So I guess that the DApp need to requests users some information when they first start it and those information are later used by the DApp to create the document. A sequence about this should be like:

I'm sorry for the quality of this Sequence but I hope I've cleared a little bit more the situation:

• No google/third-parties involved IMO (at least during this process).

About the posts, I think there's no need to store them based on users, but maybe they can be stored all together based on subspaces, then filtered based on each users interests.
I hope I got this right, let me know @HarleyAppleChoi .

Oh btw, about location...how do we get it? Should we update the post structure for it?

[HarleyAppleChoi]

@bragaz User's interests need to be uploaded inside parcel by the user itself using user identity. The I am thinking if that the user front end(dApp, like Mooncake but not the Desmos chain) can directly save the user interest (user activities) inside parcel though Tank Parser.

I think there's no need to store them based on users, but maybe they can be stored all together based on subspaces, then filtered based on each users interests.

Do you mean we group the users by subspace and filter them base on user interest? But how do we group the user by subspace?

Oh btw, about location...how do we get it? Should we update the post structure for it?

User interest information are not supposed to save on Desmos. That is sake of user privacy. What I want is to get Post_ID returned to dApp(Mooncake etc) so that front end dApp can save user interest on tank. Therefore, to save location we can get location directly from the frontend app and parse it to the parser

Do that work?

[leobragaz]

User's interests need to be uploaded inside parcel by the user itself using user identity.

I've told you that cause I've read this inside the docs:
Parcel allows your application to upload documents on behalf of other users, or identities, on the platform.(link)

Do you mean we group the users by subspace and filter them base on user interest? But how do we group the user by subspace?

No what I meant was that maybe it would be a good idea to store posts based on their subspaces instead of users.

User interest information are not supposed to save on Desmos. That is sake of user privacy. What I want is to get Post_ID returned to dApp(Mooncake etc) so that front end dApp can save user interest on tank. Therefore, to save location we can get location directly from the frontend app and parse it to the parser
Do that work?

I think so but I'm not an expert in front-end so I'm not 100% sure

[HarleyAppleChoi]

on behalf of other users, or identities, on the platform

In order for user to upload document, user need to send document to a middleware service (Tank), and Tank will upload the document on behalf of the user. The user can later view the and see who access the document on Oasis Steward.

[RiccardoM]

To me, this system seems very complicated and filled with gaps that can make it useless. Let me explain why. Considering all you have written:

1. Interests are uploaded by the DApp on the user profile.
2. Other DApps can access the interests and suggest the posts.

Now, even without considering the other things (i.e. how posts are stored and then retrieved), I think there is a big flaw here: what if there is not a single DApp that uploads the user interests inside the user profile?

The whole system would be useless because the other DApps would not have the opportunity to read the interests. Unless there is someone doing this job (which is why I put Google as a third party in my scheme), other DApps would have each one to

1. Get the interests from the user
2. Use those interests

This seems the worst UX that can be imagined. Why would I, as Mooncake, want to upload the user interests on Oasis instead of handling them directly? I would want to use them if they are already there, but not upload them by my own.

If this is the case, I think it's better to either:

1. Find a solution that does not require the DApp to upload the interests by its own, or
2. Do not use Oracle at all and use instead something similar to a distributed social analysis system detailed here.

All in all, Desmos-based DApps should not even care about the user data to get meaningful information to target them with specific posts. We can extrapolate useful information even without knowing the identity of each person, simply based on their behavior in the platform

[HarleyAppleChoi]

what if there is not a single DApp that uploads the user interests inside the user profile?

Do that mean user do not want any user interest stored in the system, extends to prefer not having any recommendation?

Unless there is someone doing this job (which is why I put Google as a third party in my scheme), other DApps would have each one to

What is the point to have third party like Google to collect the data without user having control of which data should be collected. The real problem here is tackling the current issue of Google or other data collection service that the end user do not have access or control of what data is stored.

We can extrapolate useful information even without knowing the identity of each person, simply based on their behavior in the platform

Post, comment and reaction are user behaviour right? They are already here. All the thing are handled by DApp. Users won't notice anything. What user need to do is clicking the like button and the DApp would send the message directly to Parcel without putting that on Desmos chain. We would not want the personal behaviour data to exposed on Desmos which is not encrypted. If people just clicked but not doing reaction on the posts there is no way to tell and do any recommendation.

Maybe I label it wrong on my graph, my bad. The "end user" should be "DApp", like Mooncake but not real human end user.

[RiccardoM]

The main thing that I still don't understand is: why do we need Oasis?

Form what I understood, it's going to be the DApp to collect the user behavior data, and it's going to be the DApp to use such data to recommend the posts that better suite such behavior. Now, why is Oracle so important? Can't the DApp simply put that data inside their server and use it later, just like Twitter does right now? Al Desmos users will be completely anonymous, and their personal data will never be asked by anyone, so why even bothering protecting something that they are not going to give us in the first place?

I would understand if we needed to have the user's personal data (eg. name, surname, age, etc). But we don't. This is the whole point of Desmos: create a protocol that allows to build social networks that do not require users' personal data to work.

As I already mentioned, the recommendation system can work simply by tracking the user likes/comments/follows, etc. If a DApp wants to track the in-app behavior, they can do that on their own. I don't think this is something that Desmos should care about. We are just a protocol to create social networks. It's going to be the DApp developers' job to think how to analyze the user data.

[HarleyAppleChoi]

Oasis act as a database that just like twitter but that is encrypted with public key private key encryption on blockchain by user account. The main idea of Oasis is the users can keep track of what data is used and what data analysis is taken in place and used by whom. Only like, comment, post, such behaviour data is taken in to account on recommendation. User's personal data (eg. name, surname, age, etc) do not need to be in the account at the moment.

It's going to be the DApp developers' job to think how to analyze the user data.

Yes, you are right. That is more a Mooncake (DApp) issue for how to analyse user data. However, that is also great if there is something Desmos can do to improve the workflow and make data collection easier for the DApp developers.

[kwunyeung]

@RiccardoM let me explain my view on why using Oasis.

Traditionally the ML model training is not done by the client application. The model training will be done on TPU on cloud providers such as Google, Amazon or Azure if not running private infra like Facebook. The original idea of #545 is to off load this task to protocol level so that certain actors, better not to be validators, on chain can help serving such compute while not affecting the performance of the chain and not sacrificing personal privacy to traditional IT giants.

Oasis basically is serving this purpose. Their protocol is similar to Polkadot which each ParaTime serve its own purpose. The consensus layer only make consensus on the result of the ParaTime. Parcel is one of the ParaTimes which runs on Oasis. The benefit of it is that the user's personal sensitive engagements, not limited to likes/comments/follows, such as device type, screen time, search frequencies, gestures, location, etc are being store on the privacy first infra provided by Parcel but not in public chain data or a single application. The model basically rely on the trust between end users and Parcel. End user grants accessible rights of those privacy protected data to the app which request compute running on Parcel.

It's going to be the DApp developers' job to think how to analyze the user data.

If we take Mooncake as an example, this is the job Mooncake should take care of. Mooncake will serve as an interface to get consent from the end users for permission on running such compute on Oasis. It will help training a model that would based on the user's behavioural profile. And then that model can be used back on Mooncake itself to give recommendations by pulling posts from chain directly, but not pushing from a centralized system like Facebook and Twitter.

Different dApps can have their different approaches. We cannot force other dApps using traditional ways that would provide data to IT giants but we do would like to explore Oasis as a solution.

I think what @HarleyAppleChoi requesting is to have enough data relationship to build a graph for further graph machine learning. It does sound not solvable on protocol layer as when we make a post, the postID will only be available after the transaction is being committed. We will have to query the tx on chain in order to get the event value. Then would this be solvable by DJuno? Isn't it this was how Mooncake making use of DJuno?