Skip to content
This repository has been archived by the owner on Feb 8, 2023. It is now read-only.

DSL for specifying a libp2p node #209

Open
jbenet opened this issue Dec 30, 2016 · 6 comments
Open

DSL for specifying a libp2p node #209

jbenet opened this issue Dec 30, 2016 · 6 comments

Comments

@jbenet
Copy link
Member

jbenet commented Dec 30, 2016

@diasdavid showed me https://github.com/ipfs/js-libp2p-ipfs-nodejs/blob/master/src/index.js

I wonder if there is room for a DSL here (or using either js or go as the DSL) for specifying a libp2p node construction, which then can have a compiler/transpiler to the libp2p language of choice.

Example

take something like this (this is obviously wrong, and though it's go-ish, it does not adhere to any language, just a toy example)

import (
  Peer "libp2p/core/peer"
  Kademlia "libp2p/other/kademlia"
  ip6 "libp2p/transports/ip6"
  ip4 "libp2p/transports/ip4"
  tcp "libp2p/transports/tcp"
  udp "libp2p/transports/udp"
  utp "libp2p/transports/utp"
  mDNS "libp2p/peerDiscovery/mDNS"
  Bootstrap "libp2p/peerDiscovery/bootstrap"
  Providers "libp2p/contentRouting/providers"
  upnp "libp2p/nat/upnp"
  natpmp "libp2p/nat/natpmp"
  holepunch "libp2p/nat/basicHolepunch"
  circuitRelay "libp2p/relay/circuitRelay"
)

type IPFSPeer Peer {
  const kad = Kademlia(this.config.Kademlia)
  
  transports {
    {ip6,ip4}/{tcp,udp/{utp, udt, quic}}  // <--- compact protocol combinations.
    
    // ^ brace combination notation means the same as v

    ip4/tcp
    ip4/udp/utp
    ip4/udp/udt
    ip4/udp/quic
    ip6/tcp
    ip6/udp/utp
    ip6/udp/udt
    ip6/udp/quic
  }
  
  peerDiscovery {
    mDNS()
    kad
    Bootstrap(this.config.Bootstrap)
  }

  peerRouting {
    kad
  }

  recordStores {
    kad
  }

  contentRouting {
    Providers(this.config.Providing, this.recordStores)
  }

  natTraversal {
    upnp()
    natpmp()
    holepunch()
    circuitRelay(this.config.CircuitRelay)
  }
}

And the above could be compiled to relevant Go code and JS code.

More trouble than it's worth

After sleeping over it, this seems like more trouble than it's worth, but i'll log this idea just in case.

@victorb
Copy link
Member

victorb commented Dec 30, 2016

Hm, right now the configuration could easily be adapted to YML/JSON and in that way, be shared between different language implementations, which is very helpful in testing (but not limited to). Similar to how we do with protobufs across the different implementations. I think it would useful and also not too costly to agree on some convention with the configuration.

@jbenet
Copy link
Member Author

jbenet commented Dec 30, 2016

i would prefer go or js because it's computable. im not sure giving up the computation (yml and json) are a win-- it may yield much more complicated/complex and hard to read/write documents. BUT i think it's worth a shot, to see what it would look like. you may be totally right and it may be precisely what we want.

@Kubuxu
Copy link
Member

Kubuxu commented Dec 31, 2016

There is also option of some simple scripting language (Lua was created for complex configuration) or simple minimal LISP/Scheme variant (R7RS was aiming to minimize size of the interpreter).

@whyrusleeping
Copy link
Member

Just seeing this now. I kinda like the idea, Would be cool to have this be a strict subset of javascript (making it easily parseable) that would allow us to easily specify a node construction.

@raulk
Copy link
Member

raulk commented Jul 27, 2020

This came into my radar today for the first time! Funnily, I implemented a DSL when I prototyped jvm-libp2p: https://github.com/libp2p/jvm-libp2p/blob/develop/src/test/kotlin/io/libp2p/core/HostTest.kt#L98. And it looks a lot like the one specified here 😀

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

No branches or pull requests

6 participants