Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Jonathan de Jong
    @ShadowJonathan
    Though then again, QUIC can be implimented at the IConnection level, since it doesn't subclass to a transport...
    Yeah nvm, no ISession, only a custom ResumableConnection or similar for resumable transports like quic
    Or even just a protocol 🤔
    But yeah, after reading that document, I think that specific things like the MultiStream protocol falls completely out of this diagram
    And can instead be attributed next to INetwork (or maybe in/with "IStrategy")
    Kevin Mai-Husan Chia
    @mhchia
    By "can resume sessions", I think it's just built in the transport? So IConnection shouldn't know those details?
    I mean
    Jonathan de Jong
    @ShadowJonathan
    (IStrategy so initial protocol negotiation and upgrades can be swapped out in the future)
    Yeah, that's why I had a derp moment
    Kevin Mai-Husan Chia
    @mhchia
    the resume things should only live in QUICTransport, just like TCPTransport.
    yeah
    Jonathan de Jong
    @ShadowJonathan
    Or maybe even on a protocol level
    Resumable connections make me excited, though
    Kevin Mai-Husan Chia
    @mhchia
    What do you mean by protocol level? You mean the protocol in libp2p?
    Jonathan de Jong
    @ShadowJonathan
    It means that nodes can't be stayed fixed to just one network, and instead can move out and about while staying connected to possibly multiple networks at once, while protocol traffic stays interrupted
    That'll be a huge benefit
    Yes, protocols in libp2p
    Not transport protocols (like ip4, ip6, dns, p2p-circuit, etc.)
    Maybe even provide a dummy IResumableConnection in the abc module so application code can see if the underlying connection is resumable, though this is superficial and only applicable in very specific use-cases
    Kevin Mai-Husan Chia
    @mhchia
    Hmm I'd think it's more appropriate to have transport configurable at runtime. I mean, when listen and dialing we specify what transport we want
    Jonathan de Jong
    @ShadowJonathan
    I haven't touched transports yet, only everything that's working above that
    Kevin Mai-Husan Chia
    @mhchia
    ah
    Jonathan de Jong
    @ShadowJonathan
    I'm currently just trying to figure out how to impliment this as compact and lightweight as possible in the abc library
    Kevin Mai-Husan Chia
    @mhchia
    i mean, you mentioned that we support quic as a protocol in libp2p, right?
    Jonathan de Jong
    @ShadowJonathan
    Yes
    TCP, udp, others
    There's many
    So of course transports need to be swappable
    And in the case of resumable connections, transport references need to be swappable in the connection's lifecycle
    Kevin Mai-Husan Chia
    @mhchia
    i just wanted to say it's a bit weird to me(transport as protocol). Since transport(tcp/udp/quic) is configured when initializing INetwork, and the protocols are run with IConnection.
    Jonathan de Jong
    @ShadowJonathan
    Protocols are initiated on top of IConnection-subclassed objects, yes
    I said specially "transport protocol" and "protocol"
    Those two are different things, when I say the latter, I mean libp2p protocols
    Sorry if I was unclear
    This is still a small part of the draft tho
    I'll definitely make an issue with this, with diagrams, to indicate current structure and proposed structure
    When I have gone through it all
    Kevin Mai-Husan Chia
    @mhchia
    nice
    sorry it's late night here, will catch up tmr.
    Jonathan de Jong
    @ShadowJonathan
    No problem, cya tomorrow
    Kevin Mai-Husan Chia
    @mhchia
    I think the refined structure looks pretty nice to me
    thanks
    Jonathan de Jong
    @ShadowJonathan
    No problem, glad to talk about this
    Jonathan de Jong
    @ShadowJonathan
    Maybe a weird question, but @pipermerriam, why is transport.tcp not in network? (libp2p.network.transport.tcp)
    Jonathan de Jong
    @ShadowJonathan
    @mhchia question, is the class of INetwork actually just a "node"?
    Shouldn't it be called INode? Because Network is implying it's a class that holds information for multiple "networks", which isn't the case
    Yeah, looking at go-libp2p, it should be IHost
    Jonathan de Jong
    @ShadowJonathan
    What go-libp2p is doing, with "network", is a golang language restriction, that's why they need a seperate interface, but it makes no sense in a python class structure
    Jonathan de Jong
    @ShadowJonathan
    actually nvm, lemme make a diagram of the current situation before i start rambling about this
    Kevin Mai-Husan Chia
    @mhchia
    node is a legacy name. I'd think it's just a IHost like you said