I wouldn't tie DarkWallet to a release of libbitcoin-server. The semantics
of the protocol are very different from obelisk, so there are impacts to
the client, blockchain and server. We are talking on the order of months,
not days or weeks.

We have set up version branches in each of the repos in order to deal with
the parallel efforts. There is a current release of Obelisk (v1) operating
in the wild and needs to remain stable and maintained. BX, Airbitz, CoinKite
and others are using it. We also have breaking API changes coming in short
order, pertaining to blockchain updates and DarkWallet requirements. This
implies a next version of Obelisk (v2) being maintained as people
transition. Then we have server, with unique semantics and protobuf-based
IDL and base wire protocol.

e

-----Original Message-----
From: Libbitcoin [mailto:libbitcoin-bounces@lists.dyne.org] On Behalf Of
Amir Taaki
Sent: Thursday, November 06, 2014 4:27 PM
To: libbitcoin@???
Subject: Re: [Libbitcoin] Direct websockets server

When do we think the new server could be ready for darkwallet?
What's the blockers?
I will ask to push back release if it could be a reasonable timeframe.
Although we should have beta already (the delay is partly my fault).

On 11/07/2014 12:23 AM, Amir Taaki wrote:
> I don't mind that, the benefit though to direct native websockets
> integration is less copying and re-serialising which is more efficient.
> The intermediate step isn't necessary when we have the libbitcoin API
> directly.
>
> The Python gateway right now is very crappy since it's essentially
> single-threaded blocking translator (in Python). It stops working often.
> Something direct and integrated (in C++) would be more efficient and
stable.
>
> On 11/07/2014 12:18 AM, Eric Voskuil wrote:
>> Yes, gotta provide web-friendly protocol and serializations!
>>
>> We can easily layer web sockets over ZMQ. That gets us into the browser.
>> websocketpp sounds good, but I haven't looked closely.
>>
>> The next question is wire protocol. Using a client-side js lib the
>> protobuf messages can be made accessible. ProtoBuf.js looks good there,
>> but again haven't looked closely.
>>
>> We also have the option to map the wire protocol on the server to JSON,
>> between websockets and ZMQ. This is also relatively straightforward -
>> see pb2json.
>>
>> The harder part is getting the server up under the new/privacy protocol
>> (libbitticoin-protocol). However that task is under way.
>>
>> In the mean time someone could take this up over obelisk
>> (current/updated protocol). That just means leaving out the protobuf
>> step, which means manually mapping the ZMQ messages to JSON behind
>> websocketpp. Seems like a good path for the DarkWallet folks.
>>
>> e
>>
>> On 11/06/2014 11:30 AM, William Swanson wrote:
>>> Yes, we definitely need websockets!
>>>
>>> This last weekend, I went to the Bay Area to help mentor a Hackathon.
>>> The hackathon had over a hundred students, and they produced about 14
>>> projects. Unfortunately, every single project, without exception,
>>> relied on a centralized blockchain API like CoinBase or
>>> Blockchain.info. This is not good! Companies like CoinBase are rapidly
>>> turning into the new banking establishment, destroying the
>>> decentralization we have worked so hard to achieve.
>>>
>>> If we want to reverse this trend, we need some easy-to-use,
>>> web-compatible Blockchain data server to compete with these
>>> proprietary services. The libbitcoin-node project can certainly
>>> provide this, but not over ZeroMQ. Websockets are our best hope.
>>>
>>> -William
>>>
>>> On Thu, Nov 6, 2014 at 11:11 AM, Amir Taaki <genjix@???> wrote:
>>>> I've been playing today with websocketpp, which only depends on boost
>>>> and is still actively developed.
>>>> It's simple to use and asynchronous (based off boost ASIO) which makes
>>>> it ideal.
>>>>
>>>> Here's what I used on Ubuntu 13.10 to compile it:
>>>>
>>>> export BOOST_INCLUDES=/usr/include/
>>>> export BOOST_LIBS=/usr/lib/x86_64-linux-gnu/
>>>> scons
>>>> cd build/release/echo_server/
>>>> ./echo_server
>>>>
>>>> In another terminal window:
>>>>
>>>> sudo pip install websocket-client
>>>>
>>>> Create test.py and run it:
>>>>
>>>> from websocket import create_connection
>>>> ws = create_connection("ws://localhost:9002/")
>>>> print "Sending 'Hello, World'..."
>>>> ws.send("Hello, World")
>>>> print "Sent"
>>>> print "Reeiving..."
>>>> result = ws.recv()
>>>> print "Received '%s'" % result
>>>> ws.close()
>>>>
>>>> Other options:
>>>>
>>>> * QtWebSockets - not sure where it's used or how well developed it is.
>>>> * libwebsockets - "lightweight pure C library built to use minimal CPU
>>>> and memory resources, and provide fast throughput in both directions."
>>>>
>>>> libwebsockets seems very cool, especially the zero-copy write but it
>>>> looks more complex to use:
>>>>
http://git.libwebsockets.org/cgi-bin/cgit/libwebsockets/tree/test-server/tes
t-echo.c
>>>>
>>>> here's websocketpp for comparison:
>>>>
https://github.com/zaphoyd/websocketpp/blob/master/examples/echo_server/echo
_server.cpp
>>>>
>>>> websocketpp should be easy to natively integrate as a transport into
>>>> libbitcoin-server.
>>>>
>>>> _______________________________________________
>>>> Libbitcoin mailing list
>>>> Libbitcoin@???
>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>>> _______________________________________________
>>> Libbitcoin mailing list
>>> Libbitcoin@???
>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>>>
>>
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>