-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement users relationship #168
Comments
I have been thinking of this recently but I don't know if this should be done on protocol or dapp level. If this is on protocol level, does it mean if A follows B on Mooncake, A will automatically follow B on the other dapps? |
I think so, maybe to fix this we could add an extra |
I think that this should be left to the dApps themselves. What I image will happen is the following scenario. Suppose that we have the following relationships:
Now, suppose that Alice joins a new dApp based on Desmos. What I image it will happen is that the dApp will see the existing relationships on Desmos, and asks Alice herself to choose:
This way we have a sort of double definition of relationship, one at the protocol level (which identifies the fact that somewhere, in some dApp, the two users have a connection) and another one on the dApp level which identifies how that relationship should act. The only thing is that the first dApp to create a relationship on its level should also create it at the protocol level. The important thing to note is that the fact that some data is stored on-chain does not define how apps will use it as they will be free to use it (or not) as they wish. |
After discussing with @bragaz on a call, we decided that is better to drop the bidirectional relationship implementation. The main influencing factor behind this decision is that they actually represent something only inside the social networks that already have this concept. At the same time, Desmos is a protocol and should have only the bare minimum features to implement all the other ones instead of having more complex ones. Having only mono-directional relationships is enough to represent also bi-directional ones. Also, this allows dApp developers to handle the two-way relationship the way they think is better for their social networks. Something like Facebook might want to add another layer of confirmation before creating the connection, while something like Twitter might prefer not to do so. This is a design choice that should not be taken from us, but from people using Desmos instead. |
Feature description
In all the social networks currently existing there is a concept that bonds two users between them in a tighter relationship than the rest of the users. For Facebook, this is called "friendship", for Twitter it is called "followage", for YouTube it is called "subscription". Currently inside Desmos we do not have the way of expressing this relationship and we should definitely implement it.
Implementation proposal
One thing to not about all the above mentioned relationship is that they can be either mono- or bi-directional. Inside Twitter when you follow a user, you are the one observing his actions, and the same happens on YouTube. On Facebook, on the other hand, "friendship" expresses a mutual connection, where two friends can observe the action of one another.
Types implementation
In order to properly implement both of these concepts, I think we could define a new object as follows:
Messages implementation
The operations that two users should be able to perform are distinct based on the relationship type they want to create.
Monodirectional relationships
The only operation that should be sufficient for monodirectional relationships are the creation of the relationship itself. For this the following message should be sufficient:
Bidirectional relationship
For bidirectional relationships, due to the fact that the receiver needs to accept, the following set of operations should be defined:
The following messages should allow for all of them:
Two things should be considered about the working of bidirectional relationships:
Common operations
For both mono- and bi- directional relationship, once the relationship has been created the users taking part to it should be able to cut it off. The difference are:
Sender
of the request.In order to cut off a relationship the following message should be sufficient:
Keeper implementation
In order to support all the above mentioned, I think that the following keeper method should be enough:
Conclusion
@kwunyeung @bragaz let me know what you guys think about this proposal.
The text was updated successfully, but these errors were encountered: