A few thoughts about OpenBazaar, P2P and decentralization

Post date: Jan 6, 2015 3:25:17 PM

OpenBazaar is decentralized P2P trading / market platform.

Some history and tech stuff about decentralized networking applications:

As I've said several times, I got really disappointed when PirateBay announced that reverse proxy technology is latest cloud / peer to peer networking stuff. I was expecting them to release a fully distributed version of PirateBay as portable multi-platform client application. If they follow the latest trends they could have used WebRTC compatible communication allowing the clients to run in modern web browsers in fully P2P fashion. I know some people don't remember eMule, but it actually provided search & listing functions from Kademlia (Kad) in fully distributed manner. So when people claim that Torrent's are so awesome, they're actually stepping back in time for old times. Centralized trackers is something that Even eDonkey 2000 (ed2k) and eMule got rid a long time ago. So it would be quite natural that the file sharing systems would work fully without any need for old fashioned web sites.

Flooding based networks would also work beautifully as mesh networking, even if connectivity is partially or mostly lost. As example Bitmessage would beautifully work like Firechat, same network could be relayed to 'local' peers over adhoc wlan, bluetooth, etc. So even if mobile networks are disturbed or what ever, as long as even one peer of local mesh got connection to the 'rest of world' it would relay messages and keep everyone connected.

Yet decentralized networks can be used as tool to attack other networks, if there are bugs in the client implementation. At one point ED2K's Kad had implementation problems. Peers having the lowest or hights peer ID received absolutely huge flood of traffic, because every peer on network was checking for. So the address space didn't properly wrap around to full circle. I had 10 megabit connection back then, and I got totally DDoSed out of the network after setting peer id to all 00s or FFs. Well, I'm sad for the users who didn't realize this issue and suffered from it without ability to manually change peers DHT address. I'm also the guy who told Overnet / ED2K designers that it's better to select rarest block for download, instead always selecting randomly any available needed available block. This radically reduced number of cases where there were just a few missing blocks for a huge file preventing complete availability.

Then a few thoughts about OpenBazaar, I checked it's source.

1. OpenBazaar strangely leaks network traffic to web browser javascript client. Or maybe this is on purpose? Why? Well, because it would allow fully WebRTC based clients to work with the old fashioned client application seamlessly. Utilizing HTML5, WebRTC, indexed db, local storage, web sql, etc.
2. Project seems to be fragmented, using multiple different technologies and making parallel implementations which aren't compatible with each other and so on. It's hard to track what's happening. I've been part of some Open Source projects, but those have been much more coordinated ones.
3. It seems that many JSON messages are mix of new and old data formats. Some parts of data are in flat dictionary and some parts are in nested data structures. Everything is evolving all the time, is that good or bad, remains to be seen.
4. The Client / Server (Full P2P) client got SEED MODE, which doesn't actually do anything according the source code. AFAIK, I would see seed node peers working similarly to traditional Gnutella Peer Caches. Which were often implemented in PHP, but doesn't really matter how it's done. In seed mode I would assume the peer to keeping a very few connections on default, like 3-5. The it accepts new connections, delivered information about alive peers / nodes / markets (what ever these are called) and then almost immediately disconnects the connection, making the seed available for new connections. I personally modified my Bitmessage seed node to work like this. Instead of starting the messages database sync with new clients it simply disconnected after delivering fresh network peer information.
5. Client is currently quite messed up, it can easily form 60+ parallel TCP connections to SAME peer. Which is really bad behavior. I hope this gets fixed pretty soon. I've heard they're working on new rUDP code which would replace current ZeroMQ implementation.
6. There should be options for connectivity, number of connections to be opened etc. In case of Bitmessage I'm running my own modified client branch to change these values from originals. Currently number of peers is so low, that it's possible to remain connected to every peer, but that's of course scalability show stopper.
7. What about IPv6 support? I didn't see anything related to IPv6 and we know, IPv6 is finally coming. (?)
8. Currently it seems that only one WS connection is alive with browser. Has there been any plans for multi-tenant configurations where several markets could run on single host? What about allowing multiple browser WS connections in parallel to one host? Let's say you're running web shop or something like that? Or maybe in those cases there will be just integration between the webstore and OB which would feed data from the main system to OB so there wouldn't be any users using the OB directly. If multilple parallel WS connections are created, only latest one of the connections does receive data from server. I don't exactly understand why it's so. Probably current version is designed to be run locally with only one tab in browser. But there might be situations where different configuration would be preferred one.

I hope good luck and success for projects like OpenBazaar. I've thought writing my on P2P application(s) for several years. But I haven't yet found a good reason. Maybe it would be time to write fully mobile light secure P2P application without any centralized peers except boot strap service. But as far as I know, Wire should be something like that.

As I've written several times, decentralization, mesh and P2P are just bad for mobile platforms, because those consume CPU time, Network bandwidth and generally drain battery on battery operated devices. On severs and desktops normal P2P networks work without any problems, but on mobile platforms it's a whole different story.

If you want to comment or talk about anything, just mail me. I'll be glad to discuss anything.