Thank you for getting back so fast, I know how busy you are. My motivation for the post was your interview with Leah Zitter when she asked, "What do you want BitBay to accomplish this coming year?" You replied, "and best case scenario get some coders to work on a web based version of Halo. But the web version may not happen if the project doesn't become self-regulating. I want to focus on realistic short term goals."
This led me to believe you were dealing with limited coding resources. I was thinking there might be a fast, simple way to get the web version out. I just took a look on BitBay's site and saw you already have a full-stack JS coder (Slava) as well as several other coders, so it seems you have the bandwidth to do a complete re-write. Good on you.
The packages you mentioned (Linux and Mac) are stand-alone desktop apps. I was focusing on the web version. I was thinking WebHalo was going to be server-hosted site with the server handling all storage and socket I/O. That's why I used the terms client and server.
Now it appears you will be using a (Chrome at first?) extension to be the UI for the desktop apps. Right? The extension has full r/w access to all system storage and socket I/O. So the WebHalo extension will be able to create UDP/TCP sockets with arbitrary addresses. In fact, it will share fully equivalent functionality with the desktop apps without connecting to any host. Right?
The BitHalo is in Py2. If you were strapped for resources, you could use Transcrypt to transpile the Py to JS. Transcrypt requires Py3 as input. But then you would still have to handle the PyQt calls in some manner. But none of this is necessary since you have already coded it from scratch.
What did you mean when you said "self-regulating"? Kind of like an open source project that requires minimum input by the main author?
Bitmessage has not had a full-blown security audit. Do you view that as a concern? Do you think Loki is worth looking into?
I'm trying to get up to speed technically, but as in many other projects extensive documentation is the last step.
Disclaimer: All too often "piece of cake" transpiles to "kiss of death".
Ahh that interview. That's nice to hear you read it, that was a fun one. What I mean by self-regulating is fully decentralized. Basically the code I wrote was meant to be P2P and not modular. So to convert all of the code to JS even with a tool wouldn't work for web. Basically the Bitmessage network, the business logic and other things would prevent that from working. Bitmessage isn't very phone friendly. The team of coders has so far done a partial refactor of Halo code, they converted my Python peg logic to c++ and launched testnet, they started to code a demo of the markets with double deposit escrow. We do work on a tight budget with the bear market and all though so it's unclear if we will get the web/phone market where I envisioned it by spring or summer.
The model they set up is server based and that can not be used as a working product, only a demo. The downloadable software is already fully functional. The method I want and proposed for web is like this:
Markets go direct to IP routed from main site, peers form a master/slave group
Peers run "servers" voluntarily like docker nodes and receive signed/encrypted data from front end
Thus, the server cannot delete info before it's header expiry (no data is permanent but much is persistent)
If server breaks rules(deleting singed/encrypted data or making it illegible), the other peers replace by consensus with electing new master in list
Thus ALL web logic is client side. Clients may even check txid values on sites like chainz and our own nodes to ensure it's all correct
The current model is not that, it's just where all data goes to servers that don't process any client stuff but do centralize the market data.
The BitBay/Halo software is fully decentralized from the contracts, double deposit, bitmessage, no servers, etc. So the goal is to get the web markets to do
that. Peers must host data, that's the only proper way to shift liability away from third parties and secure users.
I don't think they use chrome extensions, just standard crypto JS libraries.
The system I want to build for WebHalo will be compatible with Desktop app because nodes will read Bitmessage for main markets and post on web (relay)
and then to communicate back both Halo and Web will know they must deal with the Web logic. Bitmessage then would only be for posting to desktop only.
Bitmessage has shown itself to be very secure. Although I've not audited all the code, the main concepts are solid. Peers encrypt and only decrypt what they
hold a key for. Channels are shared keys. Messages bounce from group to group hiding sender. Even if a sender could be correlated assuming a person
had many, many nodes it's still hard to say they are involved in enough groups to know that node is the original sender.
More importantly, encrypted messages which are channels gives plausible deniability that you can just say you aren't able to read the traffic even if you
forward it. It's very strong. Unlike TOR when it accesses unencrypted pages which means entry and exit nodes are more volatile, Bitmessage is encrypted end to end meaning no clearnet traffic is found by ISP. It's not perfect, but I think it's the best we have out there. Plus there is NO SERVERS! This is so superior to hosting an onion site in my opinion which in theory might eventually be uncovered by an ISP.
Lack of servers is the end goal to serving censorship resistant, peer to peer data. I feel Bitmessage is headed in the right direction despite the bulky POW which
can be replaced anyways with other methods such as proof you time locked funds.
We have a lot of help boxes in the code, there is some sparse documentation which is somewhat old it would be nice for someone with the technical expertise
to document all the software and code but I'm pretty much focused on looking forward for now.
I take it you are a coder or something?
