Blog‎ > ‎

OpenBazaar, Onymous, WorldVu, Telegram, BitCoin, NVM Express, AWS Lambda, ECS, CDN

posted Nov 15, 2014, 10:36 PM by Sami Lehtinen   [ updated Mar 4, 2015, 9:24 AM ]

Shorter entries:

  • Thoroughly studied OpenBazaar documentation and source code. Also see the marketing site
    It's really painful, many things are so badly named, that it's very hard to find any real patterns without extensive study and testing. Well, I made it. But there's many things to fix. Code also seems to be leaking as well as for some strange reason hangs so that peers can't connect anymore and contracts won't get stored. This means that the process requires frequent restarts. Yay! Otherwise you'll run out of memory, file handles, etc. - As they said, naming things is hard, current terminology is absolutely horrible mess. It took me several hours to figure out some of the basics, because totally different naming conventions are used in separate parts of the program. As well as mixed snake_case and CamelCase even in JSON messages. Some messages (with practically similar content) use lists, some messages use dictionaries for same purposes and so on. As example result message types: store, "store_contract", "peers" (list with dictionaries), "foundNodes" (list with lists). Some parts of documentation use XML, even if program itself only uses JSON, list goes on. Sometimes stuff is called contracts, products, listings or items? And in some cases peers, nodes, markets, stores, pages. Ugh, are we having fun yet? JSON messages got linefeeds \n in middle of data, which need to be stripped (field: PGPPubKey), etc. 
  • Operation Onymous
  • Swedish Visby class corvettes
  • WorldVu Satellite Constellation - Because SpaceX is talking about dense world wide low orbit satellite network
  • Lightly studied Google Container Engine - Seems to be a great solution. I just wonder when OpenBazaar is available so you can easily "drop" your "shop" to any docker hosting. Btw. OpenBazaar project already constains directory with docker stuff, so it's quite clear they have thought about it.
  • Telegram Cryptanalysis Analysis. It got great examples what not to do. Also the current $300,000 for Cracking Telegram Encryption contest is quite interesting.
  • A great example, like how Bitcoin DoS protection can actually make you vulnerable by allowing you to connect only to attackers own nodes. 
  • Designing secure P2P networks is really hard, because every decision got it's own pro's and con's which not be clear at all.
  • NVM Express SSD interface
  • Quicky checked out Amazon AWS Lambda and Amazon EC2 Container Service (ECS)
  • CDN services by CDNNetworks - They have really dense network of hubs, even if service seems to be quite unknown compared to other players in the market. It's one of the CDN networks which also cover Africa and South America and China using several hubs.
WebSockets stuff:

GET /ws HTTP/1.1
Host: localhost
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://localhost:8888
Sec-WebSocket-Protocol: ws
Sec-WebSocket-Version: 13 (websocket-client-py3 0.10.0) fixed several things which are more or less broken:

Fixed hostport parameter value. Which is sent with Origin header value. Basically removed port number:

if True: # Was: port == 80:

At least Tornado webserver doesn't want to see port number in Host header when using web sockets. This hasn't been fixed in latest version, or maybe it's a bug on Tornado side? Don't know, didn't check, works now. It seems that nonstandard port should be reporetd with Host header. So the fail isn't in actually, it's on Tornado(s) side?

        if traceEnabled:
            logger.debug("send: " + repr(data))
        while data:
            l = self.sock.send(data)
            data = data[l:]

Swapped place of 1 and 2, because in original code trace statement was after the while loop, and naturally the data field was empty at that point. It seems that this fail has been fixed in 0.15.0 version of websocket client py3 library. Currently using version 0.21.