search

dat-ecosystem-archive / DEPs

Dat Enhancement Proposals. Contains all specs for the Dat protocol, including drafts. [ DEPRECATED - see https://github.com/hypercore-protocol/hypercore-proposals for similar functionality. More info on active projects and modules at https://dat-ecosystem.org/ ]
https://dat-ecosystem.github.io/DEPs
166 stars 17 forks source link

Intent DEP #53

Open martinheidegger opened 5 years ago

martinheidegger commented 5 years ago

(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.

pfrazee commented 5 years ago

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?

martinheidegger commented 5 years ago

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?

martinheidegger commented 5 years ago

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.

okdistribute commented 5 years ago

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

martinheidegger commented 5 years ago

Furthermore I came to think that it can be used for protocol optimization: If a peer identifies as browse (non-seed) then no WANT requests should be sent to this peer, as its have can be assumed that this peer doesn't intend to upload any HAVE.