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.

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

Upgrade to quic-go 0.28 to fix building with Go 1.19 #49

Open
prurigro opened this issue Sep 22, 2022 · 5 comments
Open

Upgrade to quic-go 0.28 to fix building with Go 1.19 #49

prurigro opened this issue Sep 22, 2022 · 5 comments

Comments

@prurigro
Copy link

It currently can't build if you're on Go 1.19 -- here's the issue in question quic-go/quic-go#3491

@mrusme
Copy link
Owner

mrusme commented Sep 24, 2022

Unfortuantely it's not as easy as upgrading to a newer version. quic-go comes with the IPFS stuff, which unfortunately cannot be upgraded unless go-orbit-db upgrades its dependency to IPFS.

I nevertheless gave it a try, here's what I got:

# github.com/libp2p/go-libp2p-quic-transport
../../../.go/pkg/mod/github.com/libp2p/[email protected]/conn.go:16:17: undefined: quic.Session
../../../.go/pkg/mod/github.com/libp2p/[email protected]/listener.go:96:40: undefined: quic.Session
../../../.go/pkg/mod/github.com/libp2p/[email protected]/transport.go:43:2: unknown field 'AcceptToken' in struct literal of type quic.Config
../../../.go/pkg/mod/github.com/libp2p/[email protected]/transport.go:43:49: undefined: quic.Token
../../../.go/pkg/mod/github.com/libp2p/[email protected]/transport.go:47:2: unknown field 'KeepAlive' in struct literal of type quic.Config

@prurigro
Copy link
Author

Hmm, I was hoping my lack of go skills were to blame, but it looks like you're hitting similar errors to the ones I was seeing... I guess we'll have to wait for upstream!

@mar1n3r0
Copy link

mar1n3r0 commented Oct 16, 2022

Hi guys. The creator of https://github.com/stateless-minds/cyber-stasis here. I find great inspiration in superhighway and we use a common approach. The only difference being that I am integrating orbit-db in a go-ipfs fork(https://github.com/stateless-minds/go-ipfs). I have tried to be up to date with upstream go-ipfs(now kubo) but this is simply not possible for a single person when you have a massive monolith application being worked upon by hundreds of people and especially when they are constantly introducing breaking changes as well as... re-branding of the whole package. Maybe we can maintain just one main fork together and then use separate forks of that for our projects. It's all about trying to get up to speed with kubo. If that's even possible.

P.S. I tried promoting a modular approach to go-ipfs: https://discuss.ipfs.tech/t/ipfs-as-a-modular-plug-and-play-service-system-3rd-party-integrations-and-interoperability/13600

A huge part of all these breaking changes is the fact that it's not a modular cluster of services but a monolith consisting of libraries.

Update:
I have forked fresh kubo and go-ipfs-api latest versions. All is working even go-orbit-db out of the box. I will continue adding functionality to the integration.

@mrusme
Copy link
Owner

mrusme commented Oct 25, 2022

Hey there,

@prurigro no worries, definitely not a skills issue. @mar1n3r0 has summarized the core problem perfectly - thank you!

this is simply not possible for a single person when you have a massive monolith application being worked upon by hundreds of people and especially when they are constantly introducing breaking changes as well as... re-branding of the whole package.

Full ack, the issue here isn't necessarily go-orbit-db but rather IPFS.

@mar1n3r0 I respect and envy the effort you're putting into this, but frankly speaking I'm not certain I would want to go down that rabbit hole. Superhighway84 was intended to add value to the crude IPFS layer by making use of go-orbit-db to implement a decentralized discussion system/BBS. You know, on the shoulders of giants.

Unfortunately the overall experience (not only on the development side, but also on the usage side) with IPFS hasn't been at a level at which it was clear that going the extra mile would make things significantly better for the end users (performance issues, connection issues, privacy issues/Tor compatibility, ...). The re-branding you mentioned is only another drop adding to the uncertainty about IPFS in general.

In the past few months I have therefor started to look outside the IPFS ecosystem for alternatives, just to see how smooth different waters could be sailed. I do not have any update to share yet, however, but I'd much rather be willing to try something totally different, tbh. Not out of frustration over IPFS or anything - it's nevertheless a fantastic piece of engineering - but rather out of curiosity.

@mar1n3r0
Copy link

Unfortunately the overall experience (not only on the development side, but also on the usage side) with IPFS hasn't been at a level at which it was clear that going the extra mile would make things significantly better for the end users (performance issues, connection issues, privacy issues/Tor compatibility, ...). The re-branding you mentioned is only another drop adding to the uncertainty about IPFS in general.

Unfortunately my experience has been somewhat similar but the transition to kubo was easier than expected and IPFS remains the only viable Go solution. I found integrations the way to go albeit quite time consuming and without any interest from the core IPFS team to go towards that direction.

In the past few months I have therefor started to look outside the IPFS ecosystem for alternatives, just to see how smooth different waters could be sailed. I do not have any update to share yet, however, but I'd much rather be willing to try something totally different, tbh. Not out of frustration over IPFS or anything - it's nevertheless a fantastic piece of engineering - but rather out of curiosity.

Holochain is one of the alternatives I am keeping an eye on. My main problem - it's based on Rust and I love Go for its simplicity and ease of use. I don't feel I can live with manual memory management and no garbage collection for daily use. On the other side Holochain seems to be taking the modular approach I am missing in IPFS so they seem to be more open to their community.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants