You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 23, 2022. It is now read-only.
In the current state this crate cannot be used to build any application on top of IPFS. We have a use-case which requires private swarms, custom authorisation between peers and additional network behaviour. The implementation of Transport in this crate is not extensible in its current form, so there are limitations on how we can use this crate to restrict access and define custom auth.
We would require that functionality be added to construct a Transport which satisfies the requirements of ipfs, while allowing additional protocols and upgrades to be supported. It should be possible to construct an IPFS instance using this transport, but as much as possible construction of a vanilla IPFS instance should not be compromised.
I have a WIP which I will raise as a PR soon, but if anyone has comments or feedback before I do so I will take them on board.
The text was updated successfully, but these errors were encountered:
While I don't have any solutions in mind, this is a good point. Transport at least should be possible to support. Supporting customizing or making the networkbehaviour of this crate usable in other contexts sounds more difficult. At the moment the p2p functionality of the crate is not useful, and reimplementing it without the ipfs command line use cases would be much simpler alternative to get ahead with your application.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In the current state this crate cannot be used to build any application on top of IPFS. We have a use-case which requires private swarms, custom authorisation between peers and additional network behaviour. The implementation of Transport in this crate is not extensible in its current form, so there are limitations on how we can use this crate to restrict access and define custom auth.
We would require that functionality be added to construct a Transport which satisfies the requirements of ipfs, while allowing additional protocols and upgrades to be supported. It should be possible to construct an IPFS instance using this transport, but as much as possible construction of a vanilla IPFS instance should not be compromised.
I have a WIP which I will raise as a PR soon, but if anyone has comments or feedback before I do so I will take them on board.
The text was updated successfully, but these errors were encountered: