search

mrusme / superhighway84

USENET-inspired, uncensorable, decentralized internet discussion system running on IPFS & OrbitDB
https://xn--gckvb8fzb.com/superhighway84
GNU General Public License v3.0
694 stars 24 forks source link

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

Open prurigro opened 1 year ago

prurigro commented 1 year ago

It currently can't build if you're on Go 1.19 -- here's the issue in question https://github.com/lucas-clemente/quic-go/issues/3491

mrusme commented 1 year ago

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/go-libp2p-quic-transport@v0.15.2/conn.go:16:17: undefined: quic.Session
../../../.go/pkg/mod/github.com/libp2p/go-libp2p-quic-transport@v0.15.2/listener.go:96:40: undefined: quic.Session
../../../.go/pkg/mod/github.com/libp2p/go-libp2p-quic-transport@v0.15.2/transport.go:43:2: unknown field 'AcceptToken' in struct literal of type quic.Config
../../../.go/pkg/mod/github.com/libp2p/go-libp2p-quic-transport@v0.15.2/transport.go:43:49: undefined: quic.Token
../../../.go/pkg/mod/github.com/libp2p/go-libp2p-quic-transport@v0.15.2/transport.go:47:2: unknown field 'KeepAlive' in struct literal of type quic.Config
prurigro commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.