Whisper looks like... modified RFC 6940?

wemeetagainwemeetagain Posts: 30Member
edited August 2014 in Whisper
http://tools.ietf.org/html/rfc6940

RFC 6940, or RELOAD, provides a spec for a p2p signaling network.

It basically creates an overlay network that can send messages between nodes and store small amounts of data. It specifies an abstract interface to the 'overlay layer' to easily allow for pluggable overlay networks (ex: friend-to-friend network), while also specifying a default (chord DHT) overlay algorithm.

Although it looks like it was originally designed to support the IETF P2PSIP working group, it can handle more generic message passing, and has some intriguing features for our space.

Pros:
+ Support for Clients - It suggests having simpler client nodes that are able to participate on limited resources. This could allow for mobile clients to still participate in the whole whisper aspect of Ethereum without resorting to centralized gateways.

+ Pluggable overlay algorithms - Mentioned above, it allows for other types of routing to be added after the fact. This could have uses for social networks.

+ P2P by default - default routing overlay is a chord DHT.

+ NAT traversal - ICE NAT traversal is standard in this spec. This allows for possible interoperability across all platforms, including web (webrtc).

Cons:
- Security model - Assumes a central enrollment server. This would necessarily have to be scratched and reworked.

- Possibly overkill - This spec is quite long and boring(?). It might be wy more trouble than its worth to implement all of this, maybe some 'good' ideas can still be pulled from this...

Anyone who knows more about the intent of the whisper network, I'd love to hear what works/doesn't work with RELOAD.
Post edited by wemeetagain on

Comments

  • joeydeejoeydee Posts: 12Member ✭✭
    edited August 2014
    Hi wemeetagain... I fear that at this point Whisper looks like *nothing*, since we don’t have a single word about the technologies involved. A lot of us are waiting to see some work in this branch of the Ethereum ecosystem.


    Anyone who knows more about the intent of the whisper network, I'd love to hear what works/doesn't work with RELOAD.

    I already raised a similar question here:

    https://forum.ethereum.org/discussion/1277/whisper-api-or-lib

    RELOAD/P2PSIP right now is a mess… I know people that has been on that working group in the IETF and they told me it has been in the building and continuously delayed for years. This was 2-3 years ago and still is a draft so… I wouldn’t hold my breath waiting for them to finish the spec.

    If you read about some of my proposals in the link above, one of them is taking OpenPeer as reference, which is an opinionated implementation of RELOAD, and it is in a much more advanced stage of development (with working clients and SDKs even for mobile apps).





    It also happens that the company that sponsors OpenPeer’s development (Hookflash), has among its advisors C. Jennings (Cisco), which leads the IETF group for RELOAD. Hookflash is also the proponent of ORTC, the next-gen WebRTC API.

    IMO, Ethereum with Whisper, shoudn't try to reinvent the wheel (which could delay considerably the launch), and aim for a semi-decentralised (hybrid) architecture, taking as reference any of the projects I posted in my thread... OpenPeer could be one of the best options because:

    - It implements loads of know-how by some of the best P2P communication researchers out there
    - It doesn't assume any architecture (you can go centralized, hybrid, or totally decentralized)
    - Plays nice with 3rd party login (oauth2) services and providers, from facebook to your own provider (ethereum-based provider anyone?)
    - Would perfectly suit the Etherbrowser which is built with web technologies (HTML+JS+CSS)
    - The WebRTC media stack uses the most advanced video/audio codecs (Opus/VP8) and implementations are available in many languajes (C++, Python, JS, Go, etc)

    0.02
    Post edited by joeydee on
  • wemeetagainwemeetagain Posts: 30Member
    D'oh, I should really read more, great thread.

    OpenPeer seems like a good starting place, at least least from a development time perspective.

    It seems to have a lot the components I've really been caring about:
    - Web enabled/WebRTC enabled - While the etherbrowser is a very cool concept, and I'll definitely be participating, when I envision using dapps/daos, I can't see forcing the use of that interface being a very successful strategy. IMO, you want something that is flexible, and able to work on as many interfaces as possible. Dapps should let users dip their feet in with a traditional browser, let command-line junkies use their curses interface, and allow everything in between -- or at least be open to it/ allow it on a protocol level.

    WebRTC is a good fit, since web, it seems, has been the most excluded from p2p goodness, yet holds the majority of people wanting to get connected. Other native applications can simply implement the protocol. Going the other way around though, getting something new into all the major browsers, is a lot harder. I'm sure there are tradeoffs here, like consequently being hitched to the whims of webRTC spec changes, but IMO its worth it.

    - Flexible network architecture - I guess in OpenPeer's case, a stand-in centralized network could quickly be put up for Whisper, but I really like the idea of being able to define your own network, since it seems like a core consideration for certain types of dapps and certain types of user behavior. I actually liked that RELOAD defined a 'default' overlay, and I think that could be a good strategy for Whisper, but more importantly, the choice to allow and integrate different networks remains.

    In any case, I think you're right about not re-inventing the wheel. Whether we/they go with an existing solution or tweak something for our own needs, though.. makes little difference to me.
  • joeydeejoeydee Posts: 12Member ✭✭
    edited August 2014
    I think using the WebRTC media stack is a no-brainer, you get Skype-quality communications for free. The battle is in the signaling plane...


    I guess in OpenPeer's case, a stand-in centralized network could quickly be put up for Whisper, but I really like the idea of being able to define your own network, since it seems like a core consideration for certain types of dapps and certain types of user behavior.

    You can make the OpenPeer Finders (aka SuperNodes) organise themselves as you want... chord, kademlia, etc... Even each DAPP or DAO could roll out their own architecture and the peers would still be able to communicate with peers in another DAPP. "Interoperability" they call it =)

    IMO running this Finders or SuperNodes that assist in the connection and health of the network, could be incentivized with some kind of scheme, just like miners...


    I actually liked that RELOAD defined a 'default' overlay, and I think that could be a good strategy for Whisper, but more importantly, the choice to allow and integrate different networks remains.

    You should read the Open Peer whitepaper, specially this part:

    Open Peer versus P2PSIP/Chord for Peer-to-peer Networking
  • StephanTualStephanTual London, EnglandPosts: 1,282Member, Moderator mod
    @joeydee‌ is correct, Whisper is in 'research' phase. Pointed Gav to this thread just in case :)
  • Manfred_KarrerManfred_Karrer Posts: 17Member
    I am not sure if WebRTC would be a good candidate as it uses rendezvous servers and for NAT traversal STUN/TURN servers.
    Rendezvous servers should be replaces by a bootstrap node network and STUN/TURN/ICE servers should be replaced by using other nodes in the P2P network for NAT traversal issues. Not sure how easy it is with WebRTC to use arbitrary P2P nodes replacing the servers.

    TomP2P (http://tomp2p.net) a Java library for a DHT and messaging network goes that approach (well connected nodes are used as relay nodes for firewalled nodes). Might be worth to check out, even the technology stack is different. It uses also some interesting extension for the key structure to support more complex data structures and comes with data access control features.
  • vaXvaX Austin, TXPosts: 78Member ✭✭✭
    Martin Thompson discusses "Aeron", an open-source, high performance messenger with implementations in Java and C++ that interoperate. There are no unnecessary features to bloat the implementation, yet the design is open so that it can be composed into higher level abstractions.
  • wemeetagainwemeetagain Posts: 30Member
    It appears that the Ethereum team is leveraging their underlying p2p network for Whisper, so it seems NAT traversal, signaling, using WebRTC or not, etc. becomes a lot less important (for what whisper looks like).

    However we want to hook into the network, that is left to us. We have the DEVP2P network protocol, and that can ride on whichever underlying transport and/or network that we need. The default clients currently let us connect to others just via TCP/IP (with JSON-RPC hooks), but that is just one of many possible options.

    https://github.com/feross/webtorrent/raw/master/img/network.png
  • eaglgenes101eaglgenes101 Posts: 43Member
    Honestly, to me, it seems to be more like bitmessage.
Sign In or Register to comment.