Proposal: Symbiosis Protocol #18
Conversation
| _What specific deliverables should completed to consider this project done?_ | ||
|
|
||
| - Have at least one collab adopt symbiosis protocol. | ||
| - IPFS Desktop providing services that enhances in-browser node capabilities. |
There was a problem hiding this comment.
Yes, if implemented. But question suggest maybe we need to elaborate more on this ?
Co-authored-by: Alan Shaw <[email protected]>
| ## Symbiosys protocol | ||
|
|
||
| > Protocol draws it's inspired from [DNS Service Discovery (DNS-SD)][DNS-SD] a [zero-configuration networking][] technique. | ||
|
|
||
| Wire protocol that is agnostic of transport and representation (message encoding) _(This makes it a good fit for cross thread communication and a cross network interface)_. | ||
|
|
||
| At the high level protocol allows IPFS nodes to announce services they can provide to other nodes on the network, which can be requested by connected nodes to overcome their limitations. |
There was a problem hiding this comment.
I feel the "Limited Relay" concept from @aarshkshah1992's Project Flare proposal (#23) could fit here.
Worth mentioning it as potential use case.
mikeal
added
ease:low
|
The proposal looks good but I question the confidence. Once we start implementing this I’d expect to surface many unknown unknowns. |
There was a problem hiding this comment.
This is going to need a lot of careful design work, but I think this is a great idea. Really, I think this is critical for PMF because:
- It allows users to extend IPFS without having to fork it.
- It allows users to use IPFS within their application without having to bundle it.
|
|
||
| ## Services | ||
|
|
||
| Protocol does not prescribe specific set of services with an assumbtion that they could be developed as needed. That said below are couple of examples: |
There was a problem hiding this comment.
Note: Just be careful to not fall into the "permissions" trap like Android did. There are two reasons to limit access:
- Resource Limitations: Denial of service/abuse.
- Information Security: data security, privacy, etc.
Course-grained "services" work great for enforcing resource limitations (i.e., I might want to route requests for some nodes, but only act as a bitswap "friend" for others). However, they don't work well for enforcing information security.
E.g.:
- If a parasite (?) wants to listen on a libp2p protocol, it should get its own (delegated) peer ID.
- if a parasite wants to pin something, those pins should be scoped to the parasite and not be global.
|
|
||
| Protocol defines: | ||
|
|
||
| 1. Interface enabling host node to announce services it can provide / lease. |
There was a problem hiding this comment.
I would love to see this as a libp2p protocol.
| - Local area network access | ||
| - Remote pinning | ||
| - Content routing | ||
| - Content caching |
There was a problem hiding this comment.
Also, bitswap "friends" and/or graphsync relay.
|
|
||
| Protocol does not prescribe specific set of services with an assumbtion that they could be developed as needed. That said below are couple of examples: | ||
|
|
||
| - Enhanced dialability (tunneled through the host) |
There was a problem hiding this comment.
Can also leverage the host to offload encryption (when trusted).
There was a problem hiding this comment.
This proposal is really interesting and I think it might make sense to a lot of use cases, and also to solve some of the pain points of our stack.
This will be a massive project full of uncertainty. Perhaps, the plan of action should be decoupled in smaller end to end projects for experimentation, like the delegate protocol on libp2p.
| - Neither embedded IPFS node nor IPFS client provide an adequate solution for building products in constrained environments. | ||
| - OS level node sharing with existing building blocks is impractial. | ||
| - Lack of generalized delegation protocol between nodes leads ad-hock stop-gap solutions. | ||
| - Teams are unable to plug domain specific extensions without having to fork our stack. |
There was a problem hiding this comment.
What type of domain specific extensions we are describing here? Dapp developers should create libp2p protocols
There was a problem hiding this comment.
There are bunch cases where domain specific replication strategy would be far more effective than bitswap is. In fact IPLD selectors is one example where that could be expressed a service. Another one I was thinking is textile threads, where communicating the a head you've seen is enough for other participants to know all the blocks they need to send you.
I think libp2p protocols are indeed relevant here. I think of this as a bit more higher level equivalent and designed with asymmetry in mind.
| --> | ||
|
|
||
| - Large | ||
| - Uncertainty on discovery implementation until several services are implemented. |
There was a problem hiding this comment.
We will probably need to rely on manual configuration first, even though we can add some defaults like trying default IPFS Desktop address port pair
|
Assigning to grants since it won't get worked on in the short term with current program structure. @mikeal is going to evaluate grant possibility. |
cc @hugomrdias