-
Notifications
You must be signed in to change notification settings - Fork 17
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
Intent DEP #53
base: master
Are you sure you want to change the base?
Intent DEP #53
Conversation
_(Note: this is the first DEP I authored, mentoring welcome!)_ I had the thought expressed in this DEP a while back but when working on DAT Desktop today I remembered it, so I wrote it down. This DEP - when looked at in some light - allows for some heterogeneity in the DAT network which feels good to me.
Yeah this is an interesting idea. @mafintosh has been exploring similar kinds of information in the Hyperswarm DHT to help with connection priorities. For this spec I'd be curious to explore the specific effects of different intents. Eg, for each intent, how are recipients expected to react? |
There should be no necessity of change in behavior by the recipients - connection-wise. I think adding it at this point in time would be premature. What I think might be interesting to specify is how to highlight this in a User-interface - I have ideas on it (like showing an eye-icon when there is a browser but no seed / download). Would that be enough for you? |
Hinted at by @Karissa (thx!): Intents could be very important to visualize the state of backups of a DAT: Right now hypercores do not ask other peers to share all their "have"'s because that would be way-too-much data to be sent through the network. However, having dedicated "backup" peers would make the selection easier: if a "backup" peer connects, the desktop could assume that it always "wants" to know everything that the desktop has. It could also be asked to share all "have"'s in order to identify which versions have been replicated on a "backup" peer. |
I think this is useful but also introduces some metadata which might not be desired for certain use cases, especially where high security is needed. So I think it is important it stays optional |
Furthermore I came to think that it can be used for protocol optimization: If a peer identifies as |
(Note: this is the first DEP I authored, mentoring welcome!)
I had the thought expressed in this DEP a while back but when working on DAT Desktop today I remembered it, so I wrote it down.
This DEP - when looked at in some light - allows for some heterogeneity in the
DAT network which feels good to me.