Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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

    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

    what's the "separate interface" are you referring to?

    Jonathan de Jong
    @ShadowJonathan
    Nvm, since I said that I've already been through 4 phases of thinking about this and I'm just about to come around again
    So I can't answer that question
    My assumption as to what that assertion is based on was wrong, btw
    I'm currently thinking on how I model my proposal to move everything to libp2p.abc for 0.2 or similar "the next version", so that even if external libraries come into play, everything is still fundamentally inoperable
    Because it isn't right now, it's locking it's mechanism into very specific ways of doing it, while the whole of it should be inoperable with external libraries that add additional functionality (like a lib that adds Bluetooth transport support, or some libraries that each register some protocols) without taking away the freedom of a modular system
    I admit that I'm way too over my own head with this, and that I'm probably asserting what is basically a fundamental rewrite out of sheer opinion, but I'm working out this idea till the end, so I can at least present it for concideration
    Jonathan de Jong
    @ShadowJonathan
    (inoperable -> interoperable, never make sentences on 5 hours of sleep without looking up critical words, folks)
    Moshe Malawach
    @moshemalawach
    mmhh, what is the rationale for not allowing newer coincurve libs?
    older coincurve can't be compiled on last ubuntu releases as libsecp256k1 changed a bit
    as in 10.0.0 can't be compiled while 13.0.0 works fine
    also same for a lot of requirements that bash with other libs I use
    Kevin Mai-Husan Chia
    @mhchia
    @moshemalawach I couldn't think of the reason for now. If the newer versions work, I think it is reasonable to move to newer, so are the other requirements.