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
    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.
    Moshe Malawach
    @moshemalawach
    it looks like it works so far from preliminary tests
    Kevin Mai-Husan Chia
    @mhchia
    Cool. Would you mind having a PR for this, to loosen the requirements?
    Moshe Malawach
    @moshemalawach
    will do!
    Kevin Mai-Husan Chia
    @mhchia
    thanks a lot!
    aratz-lasa
    @aratz-lasa
    Hello guys, currently I am checking the issues and trying to make PR that fix them. But if there is something you need specific help with let me know
    Moshe Malawach
    @MosheMalawach_twitter
    I am at EthCC, anyone here?
    Moshe Malawach
    @moshemalawach
    hey! coming back to work on p2p part of the code and wanted to bump py-libp2p versions eberywhere
    is it still working with asyncio or not at all anymore?
    Moshe Malawach
    @moshemalawach
    @ralexstokes or @mhchia ?
    Jason Carver
    @carver
    looks to me like it's trio-only now, but I'm not really following it
    Alex Stokes
    @ralexstokes
    @moshemalawach v0.1.5 is trio only, i believe v0.1.4 works w/ asyncio
    decentral1se
    @decentral1se
    \o/ nice to see this project! im very curious on the status / progress so far...