Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Cleanup Experimental Features #9396

Open
guseggert opened this issue Nov 10, 2022 · 4 comments
Open

Cleanup Experimental Features #9396

guseggert opened this issue Nov 10, 2022 · 4 comments
Labels
exp/expert Having worked on the specific codebase is important need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up

Comments

@guseggert
Copy link
Contributor

guseggert commented Nov 10, 2022 •
edited
Loading

This is a tracking issue for experimental features we need to either remove or promote to non-experimental. Anything that's been sitting in "experimental" status for > 6 months is game here.

See: https://github.com/ipfs/kubo/blob/master/docs/experimental-features.md
@guseggert guseggert added kind/bug A bug in existing code (including security flaws) need/triage Needs initial labeling and prioritization labels Nov 10, 2022
@guseggert
Copy link
Contributor Author

Filestore, ex #9396

@guseggert guseggert added exp/expert Having worked on the specific codebase is important need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up and removed kind/bug A bug in existing code (including security flaws) need/triage Needs initial labeling and prioritization labels Nov 10, 2022
@guseggert
Copy link
Contributor Author

From https://discuss.ipfs.tech/t/experimental-features-should-graduate-some-day/16155:

  • Raw leaves for unixfs files: even if not enabled by default, it should not be called experimental, just like CIDv1 is not.
  • Private Networks: I’m not even sure why it says it needs more documentation. Certainly more UX (like having a command or an init flag is not much work. pnets are widely used.
  • Plugins: the roadmap is too demanding since it does not even depend on Kubo. No one is going to invest in making plugins seriously if Kubo can come and decide one day that this won’t be a thing.
  • Directory sharding / HAMT: this is now default? Why is it marked as experimental?
  • AutoRelay: If we have relay v2, can we remove this from the experimental feature list? Isn’t relay v2 hole punching a code that is meant to stay even if not enabled by default?
  • Graphsync: I don’t quite understand that “next-gen graph exchange” is already dead.
  • Noise: it is not experimental, enabled by default
  • Accelerated DHT client: used anywhere where there is more than a trivial amount of CIDs needed to be annouced to the DHT. Is there a commitment to support this?

@guseggert
Copy link
Contributor Author

Accelerated DHT client: #9703

@aschmahmann
Copy link
Contributor

A few easier ones to cleanup from https://github.com/ipfs/kubo/blob/master/docs/experimental-features.md

  • Raw leaves for unixfs files: It's listed as stable not experimental in that file, but can be removed from that file
  • Directory sharding / HAMT: It's listed as replaced with automatic sharding
  • Noise: Listed as stable and enabled by default
  • AutoRelay: Given it's no longer in the experimental section seems non-experimental 😄

@Jorropo Jorropo mentioned this issue Nov 17, 2023
Merged
Jorropo added a commit that referenced this issue Nov 17, 2023
@Jorropo
graphsync: remove support for the server
f2e8478 
Updates: #9396
Closes: #6831
Closes: #6208

Currently the Graphsync server is not widely used due to lack of compatible software.
There have been many years yet we are unable to find any production software making use of the graphsync server in Kubo.

There exists some in the filecoin ecosystem but we are not aware of uses with Kubo.
Even in filecoin graphsync is not the only datatransfer solution available like it could have been in the past.

Kubo is consistently one of the fastest software to update to a new go-libp2p release.
`go-graphsync` is also developped on many concurrent branches.
The specification for graphsync are less clear than the trustless gateway one and lack a complete conformance test suite any implementation can run.
It is not easily extansible either because selectors are too limited for interesting queries without sideloading ADLs, which for now are hardcoded solutions.
This means the burden to track go-libp2p changes in go-graphsync falls on us, else Kubo cannot compile even if almost all users do not use this feature.
We are then removing the graphsync server experiment.

For people who want alternatives we would like you to try the Trustless-Gateway-over-Libp2p experiment instead, the protocol is simpler (request-response-based) and let us reuse both clients and servers with minimal injection in the network layer.
If you think this is a mistake and we should put it back you should try to answer theses points:
- Find a piece of opensource code which uses a graphsync client to download data from Kubo.
- Why is Trustless-Gateway-over-Libp2p not suitable instead ?
- Why is bitswap not suitable instead ?

Implementation details such as go-graphsync performance vs boxo/gateway is not very interesting to us in this discussion unless they are really huge (in the range of 10x~100x+ more) because the gateway code is under high development and we would be interested in fixing theses.
Jorropo added a commit that referenced this issue Nov 18, 2023
@Jorropo
graphsync: remove support for the server
ef620aa 
Updates: #9396
Closes: #6831
Closes: #6208

Currently the Graphsync server is not widely used due to lack of compatible software.
There have been many years yet we are unable to find any production software making use of the graphsync server in Kubo.

There exists some in the filecoin ecosystem but we are not aware of uses with Kubo.
Even in filecoin graphsync is not the only datatransfer solution available like it could have been in the past.

`go-graphsync` is also developped on many concurrent branches.
The specification for graphsync are less clear than the trustless gateway one and lack a complete conformance test suite any implementation can run.
It is not easily extansible either because selectors are too limited for interesting queries without sideloading ADLs, which for now are hardcoded solutions.
Finaly Kubo is consistently one of the fastest software to update to a new go-libp2p release.
This means the burden to track go-libp2p changes in go-graphsync falls on us, else Kubo cannot compile even if almost all users do not use this feature.
We are then removing the graphsync server experiment.

For people who want alternatives we would like you to try the Trustless-Gateway-over-Libp2p experiment instead, the protocol is simpler (request-response-based) and let us reuse both clients and servers with minimal injection in the network layer.
If you think this is a mistake and we should put it back you should try to answer theses points:
- Find a piece of opensource code which uses a graphsync client to download data from Kubo.
- Why is Trustless-Gateway-over-Libp2p not suitable instead ?
- Why is bitswap not suitable instead ?

Implementation details such as go-graphsync performance vs boxo/gateway is not very interesting to us in this discussion unless they are really huge (in the range of 10x~100x+ more) because the gateway code is under high development and we would be interested in fixing theses.
Jorropo added a commit that referenced this issue Nov 22, 2023
@Jorropo
graphsync: remove support for the server
f230447 
Updates: #9396
Closes: #6831
Closes: #6208

Currently the Graphsync server is not widely used due to lack of compatible software.
There have been many years yet we are unable to find any production software making use of the graphsync server in Kubo.

There exists some in the filecoin ecosystem but we are not aware of uses with Kubo.
Even in filecoin graphsync is not the only datatransfer solution available like it could have been in the past.

`go-graphsync` is also developped on many concurrent branches.
The specification for graphsync are less clear than the trustless gateway one and lack a complete conformance test suite any implementation can run.
It is not easily extansible either because selectors are too limited for interesting queries without sideloading ADLs, which for now are hardcoded solutions.
Finaly Kubo is consistently one of the fastest software to update to a new go-libp2p release.
This means the burden to track go-libp2p changes in go-graphsync falls on us, else Kubo cannot compile even if almost all users do not use this feature.
We are then removing the graphsync server experiment.

For people who want alternatives we would like you to try the Trustless-Gateway-over-Libp2p experiment instead, the protocol is simpler (request-response-based) and let us reuse both clients and servers with minimal injection in the network layer.
If you think this is a mistake and we should put it back you should try to answer theses points:
- Find a piece of opensource code which uses a graphsync client to download data from Kubo.
- Why is Trustless-Gateway-over-Libp2p not suitable instead ?
- Why is bitswap not suitable instead ?

Implementation details such as go-graphsync performance vs boxo/gateway is not very interesting to us in this discussion unless they are really huge (in the range of 10x~100x+ more) because the gateway code is under high development and we would be interested in fixing theses.
Jorropo added a commit that referenced this issue Nov 22, 2023
@Jorropo
graphsync: remove support for the server
2b347a9 
Updates: #9396
Closes: #6831
Closes: #6208

Currently the Graphsync server is not widely used due to lack of compatible software.
There have been many years yet we are unable to find any production software making use of the graphsync server in Kubo.

There exists some in the filecoin ecosystem but we are not aware of uses with Kubo.
Even in filecoin graphsync is not the only datatransfer solution available like it could have been in the past.

`go-graphsync` is also developped on many concurrent branches.
The specification for graphsync are less clear than the trustless gateway one and lack a complete conformance test suite any implementation can run.
It is not easily extansible either because selectors are too limited for interesting queries without sideloading ADLs, which for now are hardcoded solutions.
Finaly Kubo is consistently one of the fastest software to update to a new go-libp2p release.
This means the burden to track go-libp2p changes in go-graphsync falls on us, else Kubo cannot compile even if almost all users do not use this feature.
We are then removing the graphsync server experiment.

For people who want alternatives we would like you to try the Trustless-Gateway-over-Libp2p experiment instead, the protocol is simpler (request-response-based) and let us reuse both clients and servers with minimal injection in the network layer.
If you think this is a mistake and we should put it back you should try to answer theses points:
- Find a piece of opensource code which uses a graphsync client to download data from Kubo.
- Why is Trustless-Gateway-over-Libp2p not suitable instead ?
- Why is bitswap not suitable instead ?

Implementation details such as go-graphsync performance vs boxo/gateway is not very interesting to us in this discussion unless they are really huge (in the range of 10x~100x+ more) because the gateway code is under high development and we would be interested in fixing theses.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
exp/expert Having worked on the specific codebase is important need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up
Projects
No open projects
IPFS Shipyard Team
Status: No status
Milestone
No milestone
Development

No branches or pull requests
2 participants
@guseggert @aschmahmann